前回の記事から約300日経過しました。
はてなブックマークで AWS Organizations や IAM Identity Center についてコメント頂いていたので、回答しておきます。 コメントでも触れられていましたが Repro ではリセラーを通して利用しているので、リセラー管理下の Organizations で AWS アカウントが管理されています。 なので Repro では直接 AWS Organizations が利用できないので、合わせて IAM Identity Center も利用できていません。 色々ありますがリセラーの恩恵は大きいので、リセラーを通して利用しています。
前回のあらすじ
Repro では複数の環境（本番、ステージング、開発など）のリソースをすべて単一の AWS アカウントで管理していましたが、セキュリティと管理の最適化のため AWS アカウントの分離に取り組みました。
一気に全分離するのではなく、アプリケーション単位で段階的に進める方針を採用し、以下の順で分離を実施しました。
- テスト環境のリソース分離
- 内部利用リソースの分離
- dev_staging 環境の分離 (途中)
- staging 環境の分離 (未着手)
並行して Terraform による IaC 管理の強化、Atlantis 導入によるプロセス簡素化、デプロイプロセス改善を実施しました。
どこまで進んだか
2026年1月時点では、かなり進みましたが dev_staging 環境の分離が完全には終わっていません。
完了したものは以下の通りです。
- 全ての Kafka Streams Apps
- Step Functions
- Lambda
- Rails アプリケーション
- その他のアプリケーション
- RDS
- ElastiCache (Redis → Valkey)1
- EMR
- 細々した便利ツール等
dev_staging 環境の残りは自前運用している Kafka, Cassandra だけになりました。staging 環境はほぼ未着手なので、道半ばといったところです。
分離作業で得られた知見
クロスアカウントアクセスの重要性
段階的に分離を進めるアプローチでは、移行期間中に既存アカウント（admin）と新アカウント間でリソースへのアクセスが必要になります。クロスアカウントアクセスを実現するには、接続元と接続先の両方のアカウントで適切な権限設定が必要という点が重要です。片方だけでは動作しないため、トラブルシューティング時はこの点を確認するようにしました。
バージョンアップとの並行作業
分離作業と並行して RDS や EMR のバージョンアップを検討・実施する必要があり、これは想定以上に負担が大きい作業でした。特に古いバージョンを使っていた場合、分離のタイミングでバージョンアップも同時に行うか、先にバージョンアップしてから分離するかの判断が求められました。
設定の見直しと現代化
アカウント分離は、長年運用してきた設定を見直す良い機会となりました。既存の設定を現代的なベストプラクティスに沿った形へ直していく作業も並行して実施しています。
具体的には以下のような見直しを行いました。
- CloudFront の設定更新: 古い設定のまま運用していた CloudFront の設定を、現在推奨される設定に修正した2
- Kafka Client の設定統一: bootstrap servers の設定方法が複数混在していたことが判明し、この機会に統一することとした（詳細は後述）
- セキュリティグループの管理方法: 改善の余地があり、引き続き検討を進めている
- Terraform 管理の徹底: AWS リソースを可能な限り Terraform で管理下に置くよう進めている
今後の予定
残る自前運用している Kafka と Cassandra の分離を進めていく予定ですが、前述の知見を踏まえ、分離作業を円滑に進めるために以下の準備作業を先行して実施することにしました。
- Kafka Client 側の bootstrap servers 設定方法見直し
- Kafka のバージョンアップ & KRaft 移行
Cassandra については検討中です。
Kafka Client 側の bootstrap servers 設定方法見直し
Repro での既存アプリケーションにおける Kafka Client の bootstrap servers の設定方法は、いくつかの方法が混在していました。3
| 方法 | メリット | デメリット |
|---|---|---|
| IPアドレスの列挙 | 簡単で理解が容易 | 変更が大変。全てのアプリケーションのデプロイが必要 |
| DNS レコード | 変更が少し面倒。変更の伝播がアプリケーション再起動のみ | ドメイン名の変更が面倒 |
| SSM parameter | 変更が容易。変更の伝播がアプリケーション再起動のみ | 初期設定や他の方法からの移行が少し面倒 |
最も柔軟に管理できる SSM parameter に統一し、SSM parameter の値を DNS レコードにする予定です。
Kafka のバージョンアップ & KRaft 移行
現在 Kafka 3.6 + Zookeeper で運用しているのを Kafka 3.9 + KRaft に段階的に移行したいと考えています。4
- Kafka 3.6 + Zookeeper (現行)
- Kafka 3.9 + Zookeeper
- Kafka 3.9 + KRaft
- アカウント分離を実施
具体的な実行手順の検討はこれからですが、これでいけるだろうと考えています。5
まとめ
前回から約300日が経過し、AWS アカウント分離の取り組みは大きく進展しました。多くのコンポーネントの分離が完了しています。
残るは自前運用している Kafka と Cassandra のみとなりましたが、分離を実施する前に Kafka のバージョンアップ等を先行して実施する予定です。
段階的に進めるアプローチにより、大規模な環境でも着実にアカウント分離を進めることができています。staging 環境の分離も含め、引き続き計画的に取り組んでいきます。
WE ARE HIRING!
Reproでは開発者を募集しています。AWS アカウント分離のような大規模なインフラ移行プロジェクトや、Kafka などの分散システムの運用に興味がある方は、ぜひお話しましょう！
