1. はじめに
NTTドコモ 情報システム部の小寺智仁です。 現在担当しているシステムでは、エンドユーザ様向けのサイトを24 時間365 日誰でも閲覧できるように提供しております。 外部イベント要因に伴い、トラフィックが大きく変動するため、2018 年からクラウドリフト・シフトを進めてきました。 APIを数百本以上提供しており、効率的に管理するために、CI/CD化を推進しております。
従来、CloudFormation + CodePipelineでデプロイする仕組みを取っていましたが、デプロイおよび構成管理の効率化を図るため、AWS CDK + CDK Pipelinesの構成へ移行しました。 効率化を達成することはできたのですが、AWS CDK + CDK Pipelines利用時に、作業に必要なIAMロールが自動的に作成されます。結果、アカウント内のIAMロール数が増えすぎてしまいAWSのクォータに抵触してしまいました。
2. IAMロールのクォータ上限のハードリミット問題に直面
API単位でAWS CDKとCDK Pipelinesを使用して、環境作成とアプリケーションデプロイのパッケージング化を実施しています。
※パイプライン自体をパイプラインで更新できるCDK Pipelines便利ですよね。
便利に自動化したものはいいものの、実行の都度IAMロールが大量に作成されるようになってしまいました。 APIを構成する各部品(API Gatewayやlambdaなど)にアタッチするIAMロールを始め、CodePipeline、CodeBuildeの実行に必要なロールなど、パイプライン実行の都度ロールが増えていきます。 プロジェクト開始当初は共通基盤の思想の下、1つのアカウント内で複数サイトを構築していたのですが、サービスの拡大によりIAMロール数がハードリミット（引き上げ申請の上限）に抵触してしまいました。 IAMロールを追加できないことで、パイプラインの処理でエラーが発生し、デプロイが失敗する危険性がありました。
3. IAMロールのハードリミット問題を解決するための対処
IAMロール数をこれ以上追加できないため、現在の仕組みに対して短期的な対処・長期的な対処に分けて考えました。
- 短期的な対処：CDKでパイプライン毎に作成しているロールの共通化。機能間で類似ポリシーを利用しているロールを共通化。※最小権限の原則は抑えた上で共通化できるものを共通化
- 長期的な対処：環境、サービスごとにAWSアカウント分離
短期的な対処として、IAMロールの共通化を行いました。
標準的なパイプラインでは、実行の都度IAMロールが新規作成されるため、パイプライン実行時に共通利用できるロールを作成し、そのロールを各パイプラインにインポートすることでIAMロール数の増加を抑制いたしました。
具体的な対応方針として、
- CDK Pipelinesが自動作成する各ロールのポリシーを確認し、汎用的に利用できるように修正し、共通のIAMロールとして作成
- CDK Pipelinesのソースコード側で、元々はIAMロールを指定せずにCDK Pipelines が自動的に作成していた箇所を共通のロールをインポートするように修正。
によって実現することが出来ました。
ただ、増加ペースを落としても共通化できない部分があるため、いずれはハードリミットに抵触してしまいます。 今後は長期的な目標としてサービス毎にアカウントを分けていくことを考えています。 ただ、クラウドリフト・シフトした当初は共通基盤としての価値を最大化させるためにサービスを跨いで共通化されている部品があり、サービス毎にアカウントを分けていくことは単純ではありません。 アカウントを分けていくことは非常に大変ですが、AWSのベストプラクティスやサービス特性を踏まえて推進しております。
4. まとめ
IAMロール数のハードリミットを気にするプロジェクトは多くないと思います。 IAMロールの短期的な対処は、苦肉の策で「IAMロールをあまり気にしなくてもよいというCDKの良さ」を消してしまっています。 そのため長期的な目標であるサービスごとのアカウントの分離を推進しております。 今回は直面している問題の一部を切り出してご紹介させていただきましたが、プロジェクトを推進する過程で様々な問題に直面し、それを解決することを繰り返しております。 課題の解決と共に進化し続けられるシステムを目指し、ユーザ体験を向上させられるシステムを目指しております。
