現場から学ぶトラブルシューティング：AWS構築時にぶつかるセキュリティ、想定外の挙動、組織の壁

皆さん、こんにちは！アジアクエスト クラウドインテグレーション部です。

今回は、先日開催したイベント「クラウドインフラ現場のトラブルシューティング ～失敗から学ぶ最適解～」のパネルディスカッションの内容をお届けします。
クラウド構築・運用の最前線で働くエンジニア3名が、実際に直面した具体的なトラブル事例と、そこから得られた経験と教訓を深掘りしました。

1. セキュリティ回りのトラブル：SCPとIAMポリシーの罠

最初のテーマは、AWSのセキュリティ設定、特にAWS Organizationsで利用されるService Control Policy（SCP）に関するトラブルです。

事例の概要：SCPによるIP制限がAWS CloudFormationの実行を阻害

• 前提
  • AWS Organizationsを導入済みのお客様に対して、セキュリティ強化のためSCPでAWSコンソールへのIPアドレス制限をかけていた
• 問題
  • コンソールでCloudFormationを実行しようとしたところ、エラーが発生し実行できなかった
• 原因
  • IP制限を回避するため"aws:ViaAWSService": "false”ポリシーを使用していたが、サービスロールやサービスリンクロールを伴うCloudFormationでは実行できない仕様だった
  • SCPがアカウント全体に適用されるため、スイッチロール後もエラーが解消されなかった
• 対応
  • IP制限の適用先をSCPからIAMユーザーに付与するIAMポリシーに変更
    • IP制限を維持しつつ、スイッチロール後のロールはIP制限の影響を受けず、CloudFormationの実行が可能となった

教訓：セキュリティポリシーの検証の重要性

• SCPは強力だからこそ、継承の概念やサービスロール適用外といったAWSの仕様を深く理解した上での設計が必須
• セキュリティ関連の複雑なポリシー設定は、本番影響を避けるため検証環境で確実に確認することが重要
  • 今回の事例も検証段階で発覚したため、本番影響はなかった

ディスカッション：セキュリティと運用負荷のバランス

セキュリティを高めると運用負荷も高まるというジレンマに対し、パネリストからは「メリハリ」の重要性が語られました。

• 影響度で分ける：データの種類や、変更されたくないクリティカルなリソースにのみ厳格な制限をかけ、それ以外はReadOnlyなどのマネージドポリシーを活用し、制限をかけすぎない運用を心がける。
• 経験知の蓄積：失敗例や落とし穴の情報を集め、現実的な落とし所を見極めることが、適切なバランスを取る鍵となります。

2. 想定外の挙動によるトラブル：AWS Snowballとアーカイブファイルの落とし穴

次に、AWSサービスを使用したデータ移行時の想定外の挙動に関するトラブルです。

事例の概要：Snowballデータ移行でファイルパスに「./」が混入

• 前提
  • オンプレミス環境からSnowballを使用してAmazon Simple Storage Service（S3）へデータを移行する案件
  • 複数ファイルを圧縮してSnowballにアップロードしていた
• 問題
  • S3に格納されたファイル名に、先頭に./（ドットスラッシュ）が付与されていた
• 原因
  • 圧縮時にファイルパスの先頭に./が付与されていたため
    • ローカル環境での検証ではこの挙動を捉えられなかった
    • tarコマンドの影響だと考えられる
• 対応
  • Snowballデータ格納のためのスクリプト内で、アーカイブ後のファイルに対して./を削除する処理を追記した

教訓：PoC（概念検証）の重要性

• ローカル検証だけでは分からない、サービス連携部分の挙動は、実環境相当で必ず検証すべき
  • 今回の事例はPoC段階であったため、影響がなかった
  • トラブル解消以外にも、処理速度・並列処理の最適化ができた
  • SnowballからS3へ展開する際に発生するAPIリクエスト料金など、ストレージ容量以外の見落としがちな隠れたコストもPoCで把握することができる

3. 組織と人の問題によるトラブル：ドリフト検出と伝達ミス

最後のテーマは、技術的なミスではなく、組織や人為的なミスが原因で発生し、原因究明に時間を要したトラブルです。

事例の概要：無断のセキュリティグループ変更でコンテナが起動・停止を繰り返す

• 問題
  • Amazon Elastic Container Service（ECS）のコンテナが起動と停止を繰り返し、サービスが不安定となった
• 原因
  • Application Load Balancer（ALB）のヘルスチェックが失敗していたため
    • ALBのセキュリティグループのアウトバウンドルールが意図せず変更されていた
• 原因究明の経緯
  • CloudFormationのドリフト検出を実施し変更は検出されたが、意図的な手動変更があったため詳細を確認せず「インフラは問題ない」と先入観で判断
  • コンテナのメトリクスからアプリ側のリソース逼迫と判断し、アプリのバージョンを切り戻すも解決せず
  • 改めてAWS設定値を詳細に確認した結果、意図していない変更がされていることを発見
• 真の原因
  • セキュリティグループの変更は、インフラとアプリを兼務する担当者がインフラチームに無断で行ったもので、その変更がCloudFormationの意図したドリフトの中に紛れてしまったため、初期の確認で見落とされていた

ディスカッション：体制と確認の「粒度」

この事例は、技術的な切り分けの難しさと、組織体制の課題が絡み合っている点が特徴的でした。
パネリスト間では、特に再発防止策としての「権限・体制」と、原因究明時の「確認の粒度」について議論が交わされました。

1. 権限と体制の課題

• 権限の線引き：今回のように、アプリチームがインフラ設定を触る状況が把握できていれば、本来は権限を適切に見直し、インフラ部分へのアクセスを制限するなどの対策を講じるべきでした。
• 明確な分担のメリット：チーム間で作業範囲や権限を明確に分担することで、トラブルの影響範囲が小さくなるだけでなく、切り分けが迅速になります。担当箇所が限定されるため、「どこを誰が触ったか」が明白になり、調査にかかる時間が大幅に短縮されます。

2. 原因究明時における確認の粒度

原因究明に時間がかかった大きな要因として、ドリフト検出結果の確認不足が挙げられます。

• 「先入観」の排除：ドリフト検出時、意図的な変更の中に予期せぬ変更が紛れていたにもかかわらず、「インフラは問題ないはず」という先入観から詳細確認を怠ってしまいました。
• 確認粒度の重要性：今後の対策として、確認の粒度を細かくすることが教訓として挙げられました。具体的には、
  • 差分管理の徹底：ドリフト検出の対象となったリソースについて、どの設定で差分が発生しうるかを明確に管理する。特に、変更が発生した場合にそのリソースのどの設定がどのような内容に変更されたのかを明文化しておくこと。
  • ツールの活用：ファイルや設定値の差分確認には、diffツールなどを活用し、目視確認の限界を補うことが、見落としを防ぐ確実な方法となります。

また、今回はたまたまコンテナの停止というシステムの動作停止によって早期にトラブルに気づけましたが、案件のフェーズ1（機能実装がメインの段階）だったため、監視体制は未整備でした。
トラブルの早期発見のためにも、機能実装フェーズであっても、最低限の監視体制を早期に構築することが重要であると再認識されました。

教訓：組織体制と確認の徹底

• アプリとインフラの作業範囲や権限分担を明確に決め、誰が・どこを・いつ変更したかを組織全体で共有する仕組みが必須
• トラブルシューティングの際は、「ここは問題ないはず」という先入観を持たず、可能性のある箇所を一つずつ、粒度を細かく確認する必要がある

まとめ：失敗を教訓に変えるために

今回のパネルディスカッションを通して、AWS構築におけるトラブル対応の共通した教訓が見えてきました。

クラウド環境は常に変化し、新しい問題が発生する可能性があります。しかし、その一つ一つをチーム全体の教訓として昇華させていくことが、安定したシステム構築への道筋となります。

引き続き、技術イベントやブログを通じて、現場のリアルな情報をお届けしていきます。
今後のアジアクエストのイベントもぜひチェックしてください！