View a markdown version of this page

可能な限り、かつ実用的であれば、クラウドネイティブのマネージドサービスを採用する - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

可能な限り、かつ実用的であれば、クラウドネイティブのマネージドサービスを採用する

クラウドサービスを活用する方法を初めて検討するときは、チームが使い慣れているインフラストラクチャサービスや開発ツールを使用することが最善の方法のように思えるかもしれません。しかし、クラウドネイティブのマネージドサービス、特にサーバーレスオプションを選択することで、コスト、労力、複雑さを大幅に削減できます。

クラウドネイティブのマネージドサービスを利用することで、スタッフの時間と労力を要する、差別化されていない IT タスクの多くが排除されます。これらの時間と労力は、ミッションに重点を置いたアクティビティに費やす方が有効です。さらに、プロバイダーがサービスの機能を改善するにつれて、ソリューションは効率、セキュリティ、レジリエンス、パフォーマンスなどの特性における段階的な改善を自然に継承します。例えば、フルマネージドデータベースサービスは高機能なリレーショナルデータベース管理システムですが、データベースが実行される基盤となるサーバーやオペレーティングシステムをプロビジョニングおよび管理する必要はありません。これにより、自前のデータセンターや、クラウドでプロビジョニングするセルフマネージドの仮想サーバーでリレーショナルデータベースを維持する際に、通常必要となる管理タスクがなくなります。次の図は、この違いを示したものです。

セルフマネージド型データベースサービスとフルマネージド型データベースサービスの責任の比較

インフラストラクチャ管理を排除することの利点は、クラウドネイティブのマネージドサービスを、同等のセルフマネージドのアプローチと比較すると明らかです。そのため、購入またはカスタム開発したアプリケーションが実行されるコンポーネントをデプロイする必要がある場合は、時間と労力を削減するために、クラウドネイティブのマネージドサービスを使用する必要があります。

チームがクラウドでソリューションの構築、デプロイ、管理を担当する場合は、クラウドプロバイダーの差別化された機能とイノベーションを最大限に活用するために、クラウドネイティブのマネージドサービスを使用します。この戦略により、クラウドサービスを選択、統合、デプロイする際に、これらのプロジェクトに必要な時間と労力を削減しながら、レジリエンスとセキュリティを向上させることができます。クラウド戦略を成功させるには、カスタムソリューションをクラウドに移行したり、クラウドで新しいソリューションを開発したり、ライセンスソフトウェアをクラウドにデプロイしたりするときに、これらのクラウドネイティブの構成要素を採用することを検討してください。クラウドネイティブのマネージドサービスのオプションを評価するときは、以下の重要な質問を考慮してください。

  • 教育ミッションの中核となる機能に、スタッフの時間と労力をより集中させる必要がありますか?

    仮想サーバーであっても、サーバーを管理するには、システムソフトウェアのアップグレードやパッチを適用して最新の状態を維持するための時間と注意が必要です。これらのタスクを処理するマネージドサービスを使用することで、IT スタッフの時間を、組織のミッションにより密接に関係するアクティビティに振り向けることができます。例えば、コンテナをデプロイする必要がある場合は、サーバーの設定や維持が不要な AWS Fargate のようなサーバーレスのマネージドサービスを検討してください。基盤となるインフラストラクチャを調達、プロビジョニング、管理する必要がなくなるため、新機能の提供、パフォーマンスの最適化、ユーザーエクスペリエンスの向上に集中できます。マネージドサービスをセルフマネージドオプションと比較して評価するときは、この利点を考慮してください。

  • チームがクラウドネイティブのマネージドサービスを採用するには、どのような労力がかかりますか?

    クラウドネイティブのマネージドサービスを使用してソリューションを設計および実装するには、学習曲線が伴う場合がありますが、こうした労力は、ソリューションのライフタイムを通じてコスト、時間、複雑さを削減することで回収されます。クラウドコンピューティングはオンデマンドで従量制料金のため、クラウドネイティブサービスを使用すると、先行投資を抑えつつ、よりアジャイルな方法で迅速に反復や実験ができます。これにより、イノベーションが促進され、プロジェクトのタイムラインが短縮されます。ただし、これらの利点を効果的に実現するには、最適な使用パターンに関するスタッフトレーニングや、サービス固有の API に対応するコードのリファクタリングなど、サービスを採用して使用するために必要となる可能性がある事項を考慮してください。サービスが業界標準またはオープンソースの API を使用している場合でも、機能差やバージョンの不一致に対応するため、アプリケーションをリファクタリングまたは設定する必要がある場合があります。

  • 現在、インフラストラクチャをどのようにデプロイおよび管理していますか? そのレベルのコントロールを維持する必要がありますか?

    クラウドでインフラストラクチャをホストおよび管理するには、ベアメタルホスト、仮想マシン、マネージドコンテナサービス、サーバーレスサービスなど、さまざまな方法があります。現在、オンプレミス環境で仮想マシンやコンテナなどの同様のインフラストラクチャを使用している場合でも、特定のワークロードに別のアプローチが適しているかどうかを検討してください。例えば、すべてのアプリケーションを仮想マシンで実行する代わりに、アプリケーションのコンテナ化を検討し、Amazon Elastic Container Service (Amazon ECS) などのマネージドコンテナサービスを活用してください。これにはリファクタリングが必要になる場合がありますが、AWS App2Container などのツールを使用してコンテナ化を簡素化および支援できます。さらに一歩進めて、すべてのコンポーネントにサーバーまたはコンテナをデプロイするのではなく、完全なサーバーレスオプションを検討してください。サーバーレステクノロジーは、自動スケーリング、組み込みの高可用性、従量課金制の請求モデルを備えており、俊敏性の向上とコスト最適化を実現します。同時に、サーバーの管理やキャパシティ計画が不要になります。AWS Lambda などのサーバーレスコンピューティングサービスは、サーバーレスアーキテクチャの中核を成します。Lambda は一般的なプログラミング言語をサポートしており、開発者はインフラストラクチャを管理する代わりにアプリケーションコードに集中できます。ワークロードごとにこれらのオプションを検討し、学習曲線、管理オーバーヘッド、コスト、ライセンスなどの要因を考慮してください。

  • ライセンスされたソフトウェアのインフラストラクチャをデプロイおよび管理する必要がありますか?

    独立系ソフトウェアベンダー (ISV) からライセンスされたソフトウェアをデプロイおよび管理する場合、クラウドインフラストラクチャを使用してオンプレミスのデプロイを模倣することが論理的に思える場合があります。例えば、オンプレミスの仮想マシンをクラウドホスト型の仮想マシンに置き換えることを検討する場合があります。これは実行可能なオプションですが、アーキテクチャのコンポーネントのいずれかをクラウドネイティブのマネージドサービスに置き換えることができるかどうかを検討してください。例えば、セルフマネージド型データベースサーバーを、同じデータベースエンジンを実行しながら管理上の負担を軽減するフルマネージド型データベースサービスに置き換えられる場合があります。多くの ISV は、マネージドサービスを利用するクラウドアーキテクチャを既に使用しており、デプロイを簡素化するために構築済みのテンプレートを提供する場合もあります。可能な場合は、クラウドデプロイの規範的なガイダンスとサポートを提供する ISV をお勧めします。ライセンスされたソフトウェアをクラウドにデプロイする前に、クラウド環境のライセンスとオンプレミスのライセンスとの違いを理解するために、必ず ISV に相談してください。

  • マネージドサービスを使用すると、ベンダーロックインが発生する可能性があることを懸念していますか?

    多くのクラウドネイティブのマネージドサービスは、一般的な業界標準と API をサポートするように構築されています。例えば、AWS Glue や Amazon EMR などの分析サービスは、Apache Spark や Apache Parquet などの業界標準の処理およびストレージフレームワーク上に構築されています。AWS Lambda は、Java、Go、Microsoft PowerShell、Node.js、C#、Python、Ruby のコードをネイティブにサポートしています。Amazon Relational Database Service (Amazon RDS) は、SQL Server、Oracle、PostgreSQL、MySQL など、一般的なデータベースエンジンの複数のバージョンをサポートしています。サービスに独自の API がある場合、クラウドに依存しない一般的なプロトコルを使用して、ネイティブソリューションまたはパートナーソリューションが API とやり取りできる場合があります。例えば、Amazon Simple Storage Service (Amazon S3) には直接統合するためのサービス固有の API がありますが、AWS Storage Gateway を使用する場合、ネットワークファイルシステム (NFS)、サーバーメッセージブロック (SMB)、Internet Small Computer System Interface (iSCSI) などの標準ストレージプロトコルを使用して操作することもできます。運用上のオーバーヘッドを最大限削減しながら、ニーズに最適なクラウドネイティブのマネージドサービスを選択することにそれでも集中する必要がありますが、一般的な業界標準やプロトコルを使用する、または利用できるサービスが望ましい場合もあります。