ピアクラウドサービス障害をCloudWatchとRoute 53で乗り越える

[kdnakt]

セッションタイトル (必須)

• セッションのタイトルをイシュー件名に最大40文字程度で入力しました

連絡先の登録 (必須)

• 私は、こちらのフォーム に必要事項を記入してsubmitしました

セッションのアブストラクト (最大250文字) (必須)

私たちは、AWS Lambda上で提供しているシステムの機能の一部で、別のクラウドサービスをピアクラウドサービスとして利用しています。昨年、このピアクラウドサービスで大規模な障害が発生しました。私たちは、Amazon CloudWatch、Amazon SNS、AWS Chatbotを活用して障害を検知し、サービスの復旧に向けた対応を進めました。今回のセッションでは、私たちが行った対策と復旧の過程について詳しくお話しします。

セッションについての補足情報 (最大800文字) (任意)

自社のクラウドサービスの一部として、他のクラウドサービスプロバイダが提供するクラウドサービスを利用する場合、これをピアクラウドサービスといいます。

昨年、AWS Lambdaを利用して提供している弊社のクラウドサービスでは、ピアクラウドサービスの新しいAPIを利用した機能をリリースしました。しかし、リリースから2ヶ月ほどで、ピアクラウドサービス側に大規模な障害が発生しました。その結果、弊社のサービスからピアクラウドサービスへアクセスできない状態に陥りました。

幸いにも、ピアクラウドサービスは比較的短い時間で障害から復旧しました。ところが、発生した障害への対策でピアクラウドサービス側のネットワーク構成に変更があったためか、弊社のサービスからはピアクラウドサービスへアクセスできないままでした。

ピアクラウドサービスの担当者に問い合わせたところ、サービスのIPアドレスが変更となったことがわかりました。これを受けてAWSのサポートに問い合わせたものの、AWS Lambda上で正しくIPアドレスが解決されない事象については原因不明のままでした。

調査を進めたところ、Route 53のプライベートホストゾーン機能を利用すると、アプリケーションに変更を入れることなく、特定のドメインの名前解決の結果を変更できることがわかりました。こちらの変更を検証後、本番環境にデプロイして無事ピアクラウドサービスへの接続をスムーズに回復することができました。

本セッションでは、この障害に関連して、以下の内容についてお話しします。
・障害検知の仕組み
・障害発生時の状況
・復旧のために検討した構成変更
・最終的な構成
・反省点、今後の課題

セッション時間

20分

想定受講者の知識レベル（必須）

初級 - セッションの中心となるトピックについての具体的な知識がない方、これから勉強しようと考えている方向け

想定受講者の開発対象やロール・役割 (複数選択可) (必須)

DevOps / Infrastructure as Code

想定受講者の業種・業界・業態 (複数選択可) (任意)

エンタープライズ, ISV/SaaS, その他

セッションのトピック (複数選択可) (必須)

SaaS 開発, DevOps / Infrastructure as Code

セッションの技術カテゴリー (複数選択可) (必須)

サーバーレス

セッション内で登場する主な AWS サービス (任意)

AWS Lambda, Amazon CloudWatch, Amazon VPC, Amazon Route 53