AWS Startup ブログ
職種を越えて声をかけ合えるチームへ。TRUSTDOCK が AWS Fault Injection Service で始めた、本番さながらの障害訓練
障害訓練の必要性を感じていても、準備の手間を考えるとなかなか踏み出せない――普段トラブルが少ない環境なら、なおさら後回しになりがちかもしれません。
株式会社TRUSTDOCK は、オンラインで本人確認を完結させる eKYC やデジタル ID 事業を展開するスタートアップです。eKYC の導入社数は No.1（※2024年12月時点、eKYC のコア機能を自社開発しているサービスにおける導入社数。東京商工リサーチ調べ）を誇り、金融機関から自治体まで 300 社以上に利用されています。
同社の SRE チームが今回実施したのは、AWS Fault Injection Service（FIS）を活用した実機での障害訓練です。開発環境を使い、本番さながらの障害を擬似的に発生させる試みでしたが、準備に要した時間はわずか 30 分ほど。当日はエンジニアだけでなくサポートや関係部署のメンバーも参加し、技術的な学び以上に「チームのつながり」という大きな収穫があったといいます。
今回は、アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 ソリューションアーキテクトの Xinzhi Sherry Zhu と、テクニカルアカウントマネージャーの 上田 祐介が、TRUSTDOCK 技術基盤部 技術基盤グループ SRE チームの熊谷 秋久 氏にお話を伺いました。
安定しているから、障害対応の経験が積めない
Sherry：TRUSTDOCK では、かなり前から障害訓練を続けていらっしゃるそうですね。
熊谷：はい。SRE チームが立ち上がったのが 4 年半から 5 年ほど前で、障害訓練自体も 4 年ほど前から自主的に続けています。
Sherry：4 年間も継続されているスタートアップは、なかなか珍しいと思います。そもそも、どういった目的でスタートしたのでしょうか。
熊谷：一番の目的は、お客様への告知を遅らせないことです。私たちのシステムは 24 時間 365 日動いていて、多くのお客様のサービス基盤で本人確認を担っています。万が一トラブルが起きたとき、きちんとお客様へ状況を報告できるかどうかが信頼関係に直結する、というのはセールス陣からもよく聞く話です。
お客様への一次報告は、お客様ごとに異なりますが、数時間以内に行わなければならないケースも少なくありません。ところが障害対応に入ると、エンジニアはどうしても調査に没頭してしまい、周囲への情報連携が遅れてしまいがちなんですよね。事業の成長に伴って組織の体制も変わっていくので、連絡フローが今の体制でしっかり回るかを確かめる意味合いもありました。
上田：これまでは机上訓練がメインだったと伺いました。
熊谷：私が入社してからは、あらかじめシナリオを共有した机上訓練で連絡フローを確認していました。過去の Slack を見返すと、実は 4 年ほど前にも開発環境で手作業で障害を起こす訓練をやっていた記録はあるのですが。机上訓練は連絡フローの確認にはすごく役立ちます。ただ、実際の現場でエンジニアがどのツールを開き、どこを見て判断しているのかまでは、机上だけでは分からないんですよね。
上田：実際に手を動かして画面に向き合ってみないと、見えてこない領域ですね。
熊谷：そうなんです。ありがたいことに、うちのプロダクトは普段とても安定しているので、現場で障害対応を経験する機会がほとんどありません。過去にトラブルを一つひとつ乗り越えてきた積み重ねがいまの安定を支えているのですが、そのぶん今のメンバーが場数を踏めなくなっていて。それなら訓練の場で実際に障害を起こして、経験を積んでもらおうと考えました。同じ机上訓練を繰り返す段階から、一歩ステップアップしたかったんです。
Sherry：最初から実機にいかず、まずは机上でフローを固めていたのも良かったのでしょうね。
熊谷：実機の訓練は、参加者がフローを理解していないと成り立ちませんからね。机上訓練でベースを作ってあったから、今回は「障害の調査」に集中する訓練にできました。
準備の時間は取れない。それでも相談したら 30 分で動かせた
Sherry：実機での訓練をやると決めてから、どう準備を進めたのですか。
熊谷：最初は Amazon Aurora の障害挿入クエリのドキュメントを読みながら、どうやって障害を起こそうか考えていました。もっと手軽な方法はないかなと思っていた矢先、AWS Enterprise Support の定例で「最近お困りのことはありませんか」と聞いていただいたので、率直に相談してみたんです。そこで紹介されたのが FIS でした。
Sherry：定例でのご相談が、今回の訓練のきっかけだったのですね。
熊谷：はい。ただ、ちょうどその頃は業務が立て込んでいて、準備に割く時間がまったく取れませんでした。SRE はどうしても突発のタスクが入りがちですから。それで、ある日の夜に少し試してみようと触り始めたら、あっさり動いてしまって。準備にかかったのは 30 分ほどで、びっくりするくらい楽でした。これはすべての SRE におすすめしたいレベルですね。
障害訓練は当日の進行もエネルギーを使いますが、それ以上に準備が大変なんです。特に重いのがシナリオの作成です。準備の負担を考えるとなかなか踏み出せない会社も多いのではないでしょうか。そこを FIS のテンプレートがかなり解決してくれました。私は用意されていたテンプレートを使っただけですが、本当によくできていると感じました。
上田：訓練の対象となったシステムは、どういったアーキテクチャだったのでしょうか。
熊谷：アプリケーションの実行基盤には Amazon ECS on AWS Fargate を、データベースには Amazon Aurora を採用しています。他システムとの連携には Amazon Kinesis Data Streams と AWS Lambda 等を使っています。今回の訓練では、FIS でネットワークやデータベース周りの障害を起こしました。
上田：手軽さのほかに、FIS を使って良かった点はありますか。
熊谷：障害を続ける時間と開始時刻を指定できて、時間が来ると自動で元に戻る点です。この「勝手に戻る」ところが本当に良くて、当日の進行にかなり余裕が生まれました。おかげで、私 1 人で進行役と障害のシミュレート役を兼任できました。
もし FIS がなければ、進行役とは別に、裏で障害を起こしたり戻したりする SRE がもう 1 人必要だったはずです。今回は 2 時間の訓練だったので、丸々 1 人分の工数が浮いたことになります。SRE 1 名で約 10 名が参加する実機訓練を運営でき、1 回の訓練で 2 種類の障害を時間差で再現することもできました。何時間もかかっていた準備がすぐに終わったことも含めて、大きな効果でした。
シナリオは非公開。訓練当日に起きたリアルな試行錯誤
訓練の枠は 2 時間。参加メンバーは約 10 名で、エンジニアが 4〜5 名、サポートや関係部署から 4〜5 名が集まりました。冒頭の 10 分で趣旨を説明したあと、1 時間ほど実践訓練を行い、残りの時間で振り返りを実施するスケジュールです。シナリオは参加者に伏せたまま進め、プロダクトに詳しいマネージャーとテックリードには、あえてオブザーバーに回ってもらいました。
上田：マネージャーとテックリードをオブザーバーにしたのは、どのような理由からですか。
熊谷：普段の障害対応が、どうしても詳しいメンバーに頼りがちになっていたからです。今回はあえて、その 2 人に見守る側に回ってもらいました。
Sherry：当日はどんな形で訓練がスタートしたのでしょうか。
熊谷：ユーザー役に立てたメンバーから「不具合が出ています」と問い合わせを送るところから始めました。今回は障害を 2 つ用意していたので、問い合わせも 2 回送っています。
Sherry：1 つ目の対応を進めている最中に、2 つ目の問い合わせが届くわけですね。
熊谷：そうです。訓練とはいえ、現場はかなり実践的な空気感になりました。いざ調査が始まると、「このメトリクスはどこで見るんだっけ」「ネットワークの調査って、どこで何を確認すればいいの？」と、みんなで画面を見ながら試行錯誤していました。机上のやりとりだけでは見えてこなかった疑問が、次々と表に出てきた格好です。
上田：メンバーによって、調査のアプローチにも違いがありましたか。
熊谷：AWS DevOps Agent を含む AI エージェントを中心に調べるメンバーもいれば、Datadog や Amazon CloudWatch のメトリクスを追うメンバーもいました。私は進行役に徹していたので、当日の調査には加わっていません。
事後の振り返りでは、「エンジニアが調査に集中すると、周囲への状況共有が手薄になってしまう」という気づきも共有されました。これを確認できただけでも、実際に動かしてみた甲斐があったと思います。
Sherry：後日談として、印象的なエピソードもあったそうですね。
熊谷：訓練のあとに AWS DevOps Agent で原因を調べてみたところ、AWS CloudTrail の記録から「これは FIS の実験です」と見抜かれてしまいました（笑）。
上田：本番の障害調査としては、CloudTrail から直前の変更をたどるのは完全に正しいアプローチですね。ただ訓練だとネタバレになってしまうので、次回に向けた良い工夫ポイントになりそうです。
技術的な発見以上に大きかった「横のつながり」
Sherry：今回の訓練を振り返って、一番の収穫だと感じているのはどの部分でしょうか。
熊谷：収穫はたくさんありますが、障害対応の経験を積めたこと以上に、横のつながりができたことが何より大きかったです。エンジニアとサポートの連携も深まりましたし、SRE と開発チームの距離も縮まりました。SRE は関わるチームが多いぶん、すべての開発チームと個別に定例を持つのは難しいですから。
障害対応の場には、普段あまり話さないメンバーが急に集まります。みんなプロとして動いていますが、それでも「こんなことを聞いていいのかな」と遠慮してしまう場面はあると思うんです。訓練で一度一緒に動いておくと、本番でも「素朴な疑問なんですが、これは大丈夫ですか」と言える雰囲気が作れる。それが、実際の障害対応で本当に効いてきます。私はこの空気づくりがとても好きで、障害訓練の醍醐味だと思っています。
Sherry：とても共感します。TRUSTDOCK では、フルリモートで働かれている方も多いそうですね。
熊谷：働き方はチームごとに任されていて、SRE チームは基本的にはフルリモートです。エンジニアもフルリモートが多いです。それでも普段から、エンジニア同士はもちろんビジネス側やサポート側のメンバーとも和気あいあいと仕事をしていて、今回の訓練もそうした関係性を深める良い場になりました。
Sherry：振り返りの場も、かなり盛り上がったと伺いました。
熊谷：熱量が高かったですね。参加したメンバーから「またやりたい」「毎月やりたい」という声まで自然に出てきました。
朝会のあとにサクッと――開発チーム主導の訓練を目指して
Sherry：「毎月やりたい」と現場から声が上がるのは素晴らしいですね。今後の展開はどう考えていらっしゃいますか。
熊谷：SRE チームがお膳立てしなくても、開発チームだけで気軽に障害訓練ができる環境を作りたいと考えています。朝会のあとに「少しやってみようか」と声が上がるくらいの手軽さが理想ですね。
Sherry：今回の訓練をきっかけに、新しく始まった取り組みもあるそうですね。
熊谷：まだ開発中ですが、障害対応のエージェントを作ろうとしています。メンバーから「話しかけると、次にどこへ連絡すればいいかを教えてくれるエージェントが欲しい」という声が上がったんです。私たちのシステムは連携先が多く、どこでトラブルが起きたかによって連絡先が変わります。1 つのシステムで完結していればシンプルですが、そうはいかないので。あわせて、AWS DevOps Agent を Slack と連携させ、アラートの通知をトリガーに自動で調査を始められるようにする予定です。
上田：その仕組みができれば、エンジニア自身の調査負荷だけでなく、サポートへの情報共有もスムーズになりそうですね。
熊谷：そうですね。うまく連携できれば、現場の大きな助けになると期待しています。
上田：最後に、これから障害訓練を始めたいと考えているスタートアップのエンジニアへ向けて、メッセージをお願いします。
熊谷：障害訓練は、障害対応の経験を積めるだけでなく、職種やチームを越えたつながりを作れる場です。準備の大変さを考えて二の足を踏んでいる方も多いと思いますが、FIS を使えば準備の時間が取れなくても実機での訓練が始められます。
それから、今回私たちが FIS を知ることができたのも、定例や Slack で AWS の皆さんと普段から気軽にやり取りしていたおかげだと思います。日頃から気兼ねなく相談できる関係性が、SRE の業務はもちろん、プロダクトの品質向上にも直結していると実感しています。まだ AWS の担当チームとあまりコミュニケーションを取れていない会社には、ぜひ積極的に頼ってみてほしいですね。
上田：ありがとうございます。AWS Enterprise Support では、ソリューションアーキテクト（SA）だけでなく、私たちテクニカルアカウントマネージャー（TAM）にも、日々の運用の困りごとを気軽にご相談いただけます。今回のように、対話の中から次の一手をご提案できることが、私たちにとっても何より嬉しいことです。
Sherry：トラブルが少ない安定したシステムだからと油断せず、あえて障害対応の経験を積む場を作る。その取り組みが、リモート中心の働き方の中でも職種を越えて声を掛け合える信頼関係を育て、サービスへの信頼を支えているのだと深く実感しました。システムの耐障害性を高めるだけでなく、チームそのものを強くするための大切なステップですね。AWS はこれからも、TRUSTDOCK の皆さんの挑戦を支援していきます。本日は貴重なお話をありがとうございました。