サイト内検索
サイト内検索を閉じる

AWS Service Catalogを用いたAWS環境の自動構築に関する取り組み

はじめに

TISではDXの実現のため、日々新たなサービスが立ち上がっています。そんな多くの新規サービスを支えるシステム基盤は品質を担保した上で非常に高速なデリバリスピードが要求され、実現可能な基盤としてアマゾン ウェブ サービス(AWS)を積極的に活用しています。
その中で社内の体制面の特徴として、各サービス単位でAWSの開発・保守を行うのではなく、1つの基盤チームが多くのサービスに対して基盤環境を一元的に提供することでAWSに関するノウハウを集約しているという点があります。現在このスキームで扱っているAWSアカウント数は数十にのぼり、今後更に拡大することが見込まれています。
これら多くのサービスをシステム構成の観点から見た際、例として以下のような典型的な構成を複数組み合わせることでシステムの大枠が作られています。

▼REST APIをインターフェースとするシステム

▼画面機能を提供するシステム

TISの基盤チームでは約3年前の基盤提供開始時より、AWSが提供するIaCのためのサービスであるAWS CloudFormationを積極的に活用することで、インフラのコード化を実現していました。その中で独自の取り組みとして、セキュリティ関連のルール等システムを問わず共通的に設定すべき内容を事前に組み込んだ標準的なAWS CloudFormationテンプレートをチーム内で整備。各案件でそのテンプレートを活用してインフラ設計と構築を効率化することにより、少人数で各案件に対応してデリバリスピードの向上を実現してきました。
その一方で、今後更に多くのサービスをTISがお客様に提供するため、品質を保ちつつもう一段レベルの高いデリバリスピードの向上が求められてきました。このような背景と課題認識から今回、AWS Service Catalogを用いたインフラ構築自動化の取り組みを行いましたので、本記事で解説していきます。

AWS Service Catalogの概要

AWS Service Catalogとは、AWSリソースを定義したAWS CloudFormationテンプレートを複数取りまとめて管理し、それらを複数のAWSアカウントに対してデプロイ可能にするサービスです。AWS Service Catalogを活用することにより、統制をとりつつ標準化とバージョン管理を容易にし、環境の管理を行うシステム管理者(以下、管理者)の負担を軽減することができます。
また、環境を利用したい開発者(以下、ユーザー)自身が必要なリソースをデプロイできるようになることで、環境払い出しにかかるリードタイムを短縮し迅速な開発が可能になるというメリットもあります。
上記のようにAWS Service Catalogを活用することで、管理者による統制とアプリケーション開発のアジリティといった、相反する要素を両立させることが可能となります。
 
AWS Service CatalogではAWSリソース群を定義した製品と、それらを組み合わせて構成されるポートフォリオという概念があります。製品は以下の図のように複数のポートフォリオに所属させることができます。このように製品の個数を最小限にし、それらの組み合わせによりポートフォリオを作成していくことで、メンテナンスしやすい製品・ポートフォリオを作成することができます。

また、私たちのチームでは製品をプロダクトとモジュールという2つの考え方で分類しました。モジュールは上図の中のAWS LambdaやAmazon API Gateway等のように、個々のAWSリソースの情報を定義した製品のことで、1つのポートフォリオ内に複数のモジュールが存在します。

一方プロダクトは、複数モジュールを組み合わせて環境構成全体を定義した製品のことで、これは1つのポートフォリオに対して1つです。上図の中のプロビジョニング用製品がプロダクトに該当します。ユーザーは個々のモジュールを操作することは無く、プロダクトを起動することで自分が必要とする環境を一括で作成することができます。

AWS Service Catalogを活用した結果得られたメリット

①設計・構築時間の大幅な短縮

これまで複数のAWS CloudFormationテンプレートを一つ一つ管理・実装していたものが、AWS Service Catalogにおいては一つの製品を起動するだけで複数の関連リソースをまとめて作成できるため、構築完了までにかかる時間を大幅に短縮することができました。

例として、以下の図のようにAmazon ECS(AWS Fargate)上でコンテナアプリケーションを実装する環境の構築において、AWS Service Catalogによって約1時間で対応を完了する事ができました。
コンテナ実装環境に加えBlue/Greenデプロイのための仕組みまで同時に環境構築していることで、アプリケーション担当者はコンテナ内のアプリケーション開発に注力する事ができます。

▼作成したECSコンテナアプリケーション稼働環境

②IAM Userの最小権限の原則維持とユーザーによる環境構築の両立

製品を利用したいユーザーが製品を起動する際は、その製品を構成するリソースを作成できる権限が製品起動のオペレーションを行う自身のAWS Identity and Access Management(AWS IAM)Userに付与されてないと起動に失敗してしまいますが、必要以上に権限構成を変えたくない場合があります。
AWS Service Catalogの製品には、様々な制約を設ける事ができますが、そのうち「起動制約」を利用すると、各リソースを作成するのに必要な権限がなくても製品を起動する事ができます。

以下の図のように、製品の起動制約に特定のIAM Roleを指定する事によって起動するユーザー自身の持つIAM Userの権限ではなく、指定されたIAM Roleの権限を用いたデプロイが行われます。
こうして起動するユーザーの権限設定を意識することなく、また権限に変更を加える事のないまま実行を許可する事ができます。

▼起動制約を設定した製品構成の例

③ユーザーの知識レベルに依存しないガバナンスの担保

環境により適正値が変わるような設定(VPCのCIDRアドレスなど)は、製品起動時にユーザー側で入力・選択が可能なようにする一方、環境に依存せず共通化すべき設定は製品テンプレートに直接記述する事でデプロイされるリソースの品質を一定にする事ができます。
例えば、WAFを用いた製品では、様々な脆弱性に対する保護を予め設定した状態でデプロイすることにより、ユーザーが意識することなくセキュリティを担保することができるようにしています。
このように一定のセキュアなパラメータを一元的に展開できるため、標準的なセキュリティ要件に準拠するよう設定する事で、製品起動のオペレーションを行うユーザーの知識レベルに依らずガバナンスを担保することが可能です。

AWS Service Catalog利用にあたっての注意点

①IaCでの保守が困難

事象1

AWS Service Catalogは標準化したパラメータを一元的に提供できるものの、その標準にそぐわない要件がある場合は、製品起動後に手動での変更操作が必要になります。
AWS Service CatalogでデプロイしたリソースをAWS Service Catalog上で厳密に更新管理するための方法としては、以下の図のように管理者が更新した製品の新バージョンをポートフォリオに追加し、ユーザー側が新バージョンをプロビジョニング済み製品に適用する、という方法が挙げられます。

▼AWS Service Catalog上で更新管理する例

この更新管理方法ではポートフォリオが共有されている全AWSアカウントに更新したバージョンが展開されるため、特定のAWSアカウントに対してのみ個別に適用して展開するという事はできません。
そのため、特定のAWSアカウントでのみ標準化した設定ではなく固有の設定を実装する必要がある場合、プロビジョニング済み製品の更新を行うのではなく、一度デプロイされたAWSリソースに直接手動で更新を重ねていく必要があります。その場合コード上での変更管理が難しくなります。

対応策1

現時点で我々はIaCでの保守が必要とされる本番環境や本番環境同等の環境(ステージング環境など)については従前どおりAWS CloudFormationを用いた構築を行いAWS Service Catalogで提供する環境は技術検証目的の環境や期間限定のPoC用環境に限定して利用を行っております。

②同一環境内で複数のAWS Service Catalog製品が起動されることの考慮が必要

事象1

作成する製品のうち、プロビジョニング用製品以外のリソース部分を構成する製品は1つのポートフォリオに占有的に所属するわけではなく、複数の異なるポートフォリオに所属する事があります。

▼同一製品が複数の異なるポートフォリオに所属する図

そのような製品のリソースを含めて、デプロイされる全てのリソースはどのポートフォリオから何回起動されても、どのポートフォリオ製品と組み合わせても必ず一意の名前になるようにしないと、既存のリソースと名前が重複してしまい、起動に失敗してしまいます。

対応策1

リソース名を以下のような命名規則でデプロイするよう定義することで、命名規則が常に一意となるように致しました。

※下記はVPCのリソース名の例
{システム名}-{環境名}-{カタログID}-vpc-{Number}

システム名 製品を実装するシステム名。製品起動時にユーザーが入力する。
環境名 製品を実装する環境名。製品起動時にユーザーが入力する。
カタログID どのポートフォリオに属するか識別するためのID。複数の異なるポートフォリオで同一の製品を共有する場合、このIDがある事で異なるポートフォリオの製品を同じシステム名、環境名で起動してもリソース名が重複しなくなる。製品のテンプレートにあらかじめ記述されているので、ユーザーが編集する必要はない。
Number 同一製品を同一システム名、環境名で起動する際の起動回数。
回数が増えるごとに数字を繰り上げていく。(例:01⇒02)
このNumberがある事で何回同一製品を起動してもリソース名が重複しなくなる。製品起動時にユーザーが入力する。
事象2

リソース名とは別に、起動時のパスと呼ばれるものも意識する必要があります。
複数のポートフォリオに所属している製品を起動しようとした時、リソース名が既存リソースと重複しないようにしたにも関わらず、起動に失敗してしまう事がありました。

その際にAWS CloudTrailに出力されていたエラー内容が以下となります。
"More than one launch path ids exist. Please specify the launch path id"

launch path については公式ドキュメントにおいて、起動する際に指定された製品へアクセスするためのパスであるとの記載があります。
実際に対象環境にlist-launch-pathsを実行し表示してみると、複数ポートフォリオに所属している製品にはlaunch pathが複数存在している事が分かりました。複数のパスが存在している事から、起動時にどのパスで起動すべきか判別されず、起動に失敗してしまったと考えられます。

対応策2

本事象への対応としてプロビジョニング用製品のテンプレートで明示的にどのポートフォリオの製品として起動するかを明記する必要がありました。
以下は、プロビジョニング用製品のテンプレートの中で、ECS Clusterの製品を起動する部分の記述です。

PropertiesのPathNameという箇所で、ポートフォリオ名が入力されるようにしています。
こうする事によって、起動時にどのポートフォリオに属する製品として起動するか判別され、起動に成功することができました。

事象3

構成されるリソースのうち、IAM Roleなど1環境に1つあればよいリソースは初回起動時のみデプロイをして2回目以降同一製品を起動する際は何度も追加デプロイする必要がない場合があります。特にAWSの仕様上固定のリソース名でデプロイしないといけない等の理由であらかじめ策定した命名規則が適用できないリソースを作成しないといけない場合があります。
例えば、AWS Cloud9を作成する製品の場合、Systems Manager 経由でのセッション管理ができるよう作らなければいけないリソースがあります。それがAWS Cloud9用のサービスロールとIAM インスタンスプロファイルと呼ばれるリソースなのですが、それぞれAWSCloud9SSMAccessRoleと AWSCloud9SSMInstanceProfileという名前で作成される事がAWSの仕様で指定されています。この場合複数回の製品起動は名前の重複が避けられずに失敗してしまいます。

対応策3

初回起動用の製品と2回目以降起動用(追加構築用)の製品を分けて作成し、1環境に1つだけあればいいリソースは初回起動用の製品の起動時にのみデプロイし、追加構築用の製品ではそれ以外のリソースがデプロイされるようにしました。
以下は製品構成例の図となります。

▼初回用と追加構築用に起動する製品を分けた例

以上のようにAWS Service Catalogを有効に活用するためには考慮すべき点というものがあります。
特に今回我々は最終的に多数のユーザーがAWS Service Catalogを利用することを念頭に置いた提供方式を想定しているため、多くのユースケースに対応できるよう検討が必要でした。但し、AWS Service Catalogの機能を活用することにより一元的なテンプレートの管理や適切なユーザー権限の維持・ガバナンスの担保といった大きなメリットを得られていることから、今回の仕組みにおいてAWS Service Catalogを用いたことは正解であったと考えております。

おわりに

これまでAWS Service Catalogの活用とそのメリット・注意点について解説しました。最後に今後の活用方法として、AWS Service Catalogが適している場面について説明します。

1つ目の場面は技術検証用の環境構築をする場面です。
AWS Service Catalogのメリットの一つとして構成の標準化があげられますが、その反面AWS Service Catalogでデプロイしたリソースは一元管理されているために、デプロイ時に個別のカスタマイズを実施することが難しくなります。また、AWS Service Catalogでデプロイしたリソースを変更するためには手動での変更が必要となり、保守性も低下します。このような特性を考慮すると本番環境の構築などに活用するのは現状では難しいと思われます。しかし、技術検証用など一時的に利用する環境であれば保守性を考慮する必要が無くAWS Service Catalogの利用が適しています。また、AWS Service Catalogを活用することで技術検証用の環境をスピーディに払い出すことができ、他のより本質的な部分に注力することが可能になります。

2つ目の場面は共通の運用機能など、環境ごとのカスタマイズが不要な機能を構築する場面です。
最初にご説明した通り、我々の基盤チームが扱うAWS環境は数十と多数あり、それらに対して共通の運用機能を導入しています。例えば、長期間使用していないIAM Userの認証情報を自動的に削除する仕組みや、Amazon CloudWatch Logsに出力されたログをAmazon S3に転送する機能を共通の運用機能として導入していますが、これらをAWS Service Catalogで実装し、全AWS環境に展開することで構築担当者の負荷を大幅に低減できました。
また、この機能に関してはAWS Service Catalogを使って展開することで、保守性も高まるというメリットもあります。共通の運用機能については個別のカスタマイズが不要で展開後にそのまま使用していくことになります。もし機能の追加や修正などの対応が必要な場合は、AWS Service Catalogの製品を修正、新しいバージョンとして各AWSアカウントに展開します。そして各AWSアカウントに、新バージョンを適用していくことで運用機能のアップデートを実施することが可能となります。

上記以外にも、コード化できる部分が限られていて必ず手動構築が必要なリソースや、AWS CloudFormationを用いた保守が向いていないようなリソースの構築にAWS Service Catalogが適していると考えています。このようにAWS Service CatalogによるAWS環境の自動構築を活用し、今後より多くのサービス創出をスピーディに実現していきたいと考えています。

※参考
AWS Service Catalog 管理者ガイド:https://docs.aws.amazon.com/ja_jp/servicecatalog/latest/adminguide/introduction.html
AWS Black Belt Online Seminar:https://aws.amazon.com/jp/blogs/news/webinar-bb-service-catalog-2018/

著:TIS株式会社 ペイメントサービスユニット ペイメントプラットフォームサービス部 二出川弘
TIS株式会社 ペイメントサービスユニット ペイメントプラットフォームサービス部 鴨川友輔
Modis株式会社 営業統括 ICT Solution事業本部 滝沢真知子

PAGE TOP

サービスに関する資料をご希望の方は、フォームに必要事項を入力いただき、ご送信ください。

資料を請求する

お問い合わせ
各種お問い合わせページ
お問い合わせフォーム
サービスに関するお問い合わせ
お電話
0800-600-9810
携帯電話
050-5816-9805
受付時間 9:00~12:00 13:00~17:00(土・日・祝日を除く)

更新日時:2024年3月25日 16時40分