Amazon Web Services ブログ

分散型環境における AWS Service Catalog を使用したインフラストラクチャデリバリーの標準化

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (Dev) 、品質保証 (QA) 、そして実稼働 (Prod) といった開発ライフサイクル (SDLC) の各フェーズに合わせ、環境全体で完全な分離を実現するために、個別の AWS アカウントを作成する手法を選択しています。しかしながら、アカウント作成時点でアプリケーションからの要件が完全に理解できていない場合、必要なインフラストラクチャコンポーネントをプロビジョニングすることが困難になり得ます。加えて、作成されたアカウントが増えるに従い、それらの異なるカウント間でのインフラストラクチャのコンプライアンスと一貫性を実現するための手法を模索しなければなりません。

AWS Service Catalog は、こういった課題に対処するため役立ちます。これにより開発者は、どのような環境においても、インフラストラクチャコンポーネントを、素早く、安全かつ簡単にデプロイできるようになります。次の図は、このワークフローを示しています。ここでは、アプリケーションにおける Dev/QA/Prod 用の各アカウントが、実稼働および非実稼働向けのインフラストラクチャコンポーネントを共有するために、AWS Service Catalog が使用されています。

お客様の多くに、AWS Service Catalog を使用するメリットは「一枚のガラス」を通すようにインフラストラクチャがプロビジョニングできることである、と捉えていただいていますが、実はこれには、製品のデプロイを自動化する機能も備わっています。前出の図にあるワークフローでは、アプリケーションのアカウントで共有している各製品は、それぞれの継続的統合/継続的デリバリー (CI/CD) パイプラインから、直接デプロイすることが可能です。これにより、コードおよびインフラストラクチャの依存関係と、各チームに分散した個別コンポーネントの所有権とを、開発者が固く結びつけることができる環境が提供されます。

このモデルからは、次のように 2 つの主要なメリットが得られます。

  1. 中心チームは、承認されたインフラストラクチャのバージョンを定義することで、コンプライアンスと標準化を実施できるようになります。
  2. アプリケーション所有者が、使用すべきインフラストラクチャコンポーネントを自身で選択できる、セルフサービス型の環境が提供されます。

次の図で、このプロセスをさらに詳細に説明しています。ここでは、インフラストラクチャの定義は Shared Services チームにより処理されます。このチームにより、アプリケーションアカウントとの間で共有する、ネットワークやコンピューティングベースのリソースに関するカタログが作成されます。アプリケーションの所有者には、各要件に最も適合するコンポーネントを決定する役割があり、各所有者は複数のバージョンをが共有できます。これらの製品は、アプリケーションの CI/CD プロセスの一環として、AWS CodePipeline などの AWS のサービスを使用してデプロイされます。この、インフラストラクチャのデプロイ手法には、セキュリティ上のメリットもあります。アプリケーションパイプラインのアクセス権限は、基盤となっている AWS のサービスではなく、最小権限を保証しながら AWS Service Catalog ポートフォリオに対し適用されるからです。

AWS Service Catalog アカウントポートフォリオの共有を活用する CI/CD パイプラインの自動構築は、次の GitHub レポジトリから Amazon ソフトウェアライセンスの下で利用可能です。

GitHub レポジトリ –  https://github.com/aws-samples/aws-service-catalog-reference-architectures/tree/master/labs/xacct-pipeline

このレポジトリには、ステップバイステップの手順と、CI/CD パイプラインを AWS CodePipeline サービスにより作成する際に必要となる AWS CloudFormation テンプレートが記載された、read-me ガイドが含まれています。

AWS Service Catalog の CI/CD パイプラインソリューションについて

この記事では、AWS Service Catalog によりインフラストラクチャのデリバリーを行う、CI/CD パイプラインを構築する方法をご紹介していきます。ここでのシナリオでは、共有サービスチームが Virtual Private Cloud (VPC) のランディングゾーンをすでに定義済みです。このチームは、アプリケーションチームの CI/CD パイプラインで、このインフラストラクチャを利用可能にしようとしています。

このデモは、次のような領域をカバーしています。

  1. 共有サービスアカウント内において、承認済みの VPC テンプレートをホスティングするための、AWS Service Catalog ポートフォリオのプロビジョニング
  2. アプリケーションアカウントとの間での VPC 製品の共有
  3. AWS CodePipeline を使用しての CI/CD パイプラインの作成
  4. 新たに構築した VPC への、VPC 製品と Amazon EC2 インスタンスのデプロイ

これらのプロセスを、次のアーキテクチャ図に示します。

AWS Service Catalog の CI/CD パイプラインソリューションのデプロイ方法

Git レポジトリでは、必要なすべての AWS CloudFormation テンプレートとread-me ガイドが提供されます。必要な AWS Service Catalog インフラストラクチャを共有サービスとアプリケーションアカウント内に構成するために、分割された CloudFormation テンプレートがサンプルの CI/CD パイプラインとともに用意されています。これらの CloudFormation テンプレートの実行方法と実行場所についての詳細な説明は、read-me ガイドで読むことができます。

このガイドを通じ、ユーザーは参考アーキテクチャを構築するための、次のようなプロセスを体験できます。

共有サービスアカウント内:

  1. ローカルの Amazon S3 バケットへの VPC CloudFormation テンプレートのアップロード
  2. AWS Service Catalog ポートフォリオを作成しての、実稼働インフラストラクチャのホスティング
  3. VPC インフラストラクチャ用の AWS Service Catalog 製品の作成
    • 製品、サポート内容、バージョンに関する詳細の提供
    • Amazon S3 バケット内に保存された VPC テンプレートの参照
  4. マスター AWS Service Catalog ポートフォリオの、アプリケーションアカウントとの共有

アプリケーションアカウント内:

  1. 共有サービスアカウントからの、AWS Service Catalog ポートフォリオ共有の受け入れ
  2. 次の、各 AWS Identity and Access Management (IAM) ロールの作成
    • 各種のパイプラインステップを起動する権限を持つ、CodePipeline サービスを提供する IAM ロール (例: PipelineRole)
    • AWS Service Catalog 製品を起動する権限を持つ、CloudFormation サービスを提供する IAM ロール (例: CFNLaunchRole)
    • ローカルの AWS アカウントに製品をデプロイする権限を持つ、AWS Service Catalog サービスを提供する IAM ロール (例: ProductLaunchRole)
  3. VPC インフラストラクチャ用の、ローカルな AWS Service Catalog 製品の作成
    • CloudFormation が製品を起動できるようにするための、IAM CFNLaunchRole とポートフォリオとの関連付け
    • 共有サービスの AWS Service Catalog からローカルカタログへの、VPC 製品の追加
    • AWS Service Catalog アカウントにローカル AWS アプリケーションアカウントでの製品デプロイを許可するための、起動制約の作成、および、 ポートフォリオへの IAM ProductLaunchRole の割り当て
  4. CodePipeline アーティファクトに対しソースコードレポジトリとして機能する、ローカル Amazon S3 バケットの作成
  5. 次のステージを備える CodePipeline ワークフローの作成:
    • 先に作成済みの S3 アーティファクトにファイルがアップロードされた際にトリガーされる、Amazon S3 ソースステージ
    • AWS Service Catalog VPC 製品をデプロイする、VPC デプロイステージ
      • Amazon S3 アーティファクト内からの VPC テンプレートの参照
      • VPC CloudFormation テンプレートを起動する IAM、CFNLaunchRole の使用
    • 新たに構築した VPC に EC2 インスタンスをデプロイする、Amazon EC2 デプロイステージ
      • 前出の S3 アーティファクト内からの Amazon EC2 テンプレートへの参照
      • Amazon EC2 CloudFormation テンプレートを起動する IAM、CFNLaunchRole の使用
    • AWS Service Catalog の自動パイプラインのテスト
      • ステップ 4 で作成した S3 バケットへの、ソースコードアーティファクトのアップロード
        • VPC は、AWS Service Catalog 経由でデプロイされます。
        • EC2 インスタンスは、この VPC 内で起動されます。
      • パイプラインが、ネットワークとコンピューティングリソースのデプロイを完了するまでの間の待機

まとめ

本ブログ記事内で使用したアーキテクチャは、簡単な CI/CD パイプライン内から共有の AWS Service Catalog 製品を呼び出すことで、インフラストラクチャのデリバリーを標準化するプロセスを示しています。お客様は、ここでのソリューションを修正することで、たとえばマスターカタログを追加のインフラストラクチャコンポーネントで構成したり、AWS CodeBuildAWS CodeDeploy といったサービスを使用してアプリケーションコードのコンパイルやデプロイを行うといった、より複雑なシナリオに使用できます。本稿で書いたとおり、AWS Service Catalog では、セキュアで柔軟なデリバリーフレームワークを、お客様に提供しています。

著者について

Kristopher Lippe は、ボストンを拠点にしている、AWS のエンタープライズソリューションアーキテクトです。彼はテクノロジーの信奉者で、お客様がビジネスにおける複雑な課題のための革新的ソリューションと出会えるように、熱心に協力しています。彼の主な専門分野は、ストレージ、ネットワーキング、およびセキュリティです。 お客様によるクラウド導入を手助けしていないときは、読書やゴルフ、そして自宅のリノベーションなどを楽しんでいます。