障害発生！ 口を挟むCTO！ SREたちは何と向き合ったのか？
今回の大会には、NECネッツエスアイ株式会社、アイレット株式会社、イオンスマートテクノロジー株式会社、株式会社JR東日本情報システムなどのエンジニアが参加した。参加者は、所属企業ごとに3名5チームに分かれ、障害対応を行った。お題となる仮想チャットサービスには、大会の様子を見守る観戦者も書き込むことができる。観戦者も、サービスのユーザー役という、重要な役割を担っているのだ。
大会が始まってしばらくすると、突然サービスに繋がらなくなる。チャットのメッセージがおかしくなるといった、怪奇現象めいた異常が出現し始めた。障害の内容は、チームごとに、内容も、タイミングもバラバラだ。現実の障害でも、いつ、何が起きるかは、誰も教えてくれない。
そして障害対応が始まった。Slackベースで黙々とコミュニケーションを取るスタイル、口頭で活発にディスカッションするスタイル。チームそれぞれのやり方で、障害解消に取り組む。
各チームが対処しなければならないのは、障害だけではない。黙々と作業するチームに、CTO役のスタッフがたびたび口を挟んでくる。プレッシャーを掛けたり、やや的外れなアドバイスを与えたりと、チームをかき乱す。現場でありがちな光景に、参加者・観戦者の笑いを誘っていたが、これは単なる寸劇ではない。CTO役に現状を適切に説明できるかどうかも、重要な審査ポイントだ。観戦者からはやり取りが見えないが、実際にはカスタマーサポート役や、障害によって影響を受けるシステム担当役もおり、各チームは、Slack上でもステークホルダーに適切な説明をしなければならない。
技術的な解説を始める前に、ここで仮想チャットサービスの構成を説明しよう。アプリケーションは、フロントエンド、バックエンド、データベースからなる、シンプルな3層構造のアーキテクチャだ。各チームのアプリケーションは、Amazon EKS上に構築されたKubernetesクラスタの上で稼働し、Namespaceで区切られている。そこでは、フロントエンド、バックエンド、それぞれのPod が稼働し、Ingressによりドメインが割り振られる。
各チームのリポジトリには、アプリケーションコード、Kubernetesマニフェスト、Terraformコードが保存されている。Terraformコードの変更はHCP Terraformで自動反映され、アプリケーションコードやKubernetesマニフェストの変更はGitHub Actionsでコンテナイメージが生成・プッシュされ、ArgoCDが検知して自動デプロイする。
ObservabilityツールにはNew Relicを使用し、障害の兆候を示すアラートは、PagerDutyに自動起票される。各チームは、アラートやログを頼りに、障害の原因を切り分け、対処法を試していく。ただし現実同様、障害がモニタリングツールをすりぬけ、アラートが出ない場合もある。その際は、PagerDutyに手動で起票しなければならない。
各チームのサービスには、以下の3つの障害が発生していた。障害は同時に起きるわけではなく、1つ解決すると、次の障害がトリガーされる。
ウェブサイトへの接続ができない
何らしかの原因により、インターネット経由でウェブサイトへのアクセスができなくなってしまう。参加者はネットワークの設定やKubernetesのリソース周りを確認する必要がある。
Database不達
何らしかの原因によりバックエンドからデータベースに接続できなくなり、アプリケーションに必要な情報が表示されなくなる。参加者は、バックエンドとデータベース間の通信に問題がないかどうかや、権限周りの、アプリケーションのバグの有無などを確認して原因を絞り込んでいく必要がある。
アプリケーションのバグ
新規リリースされたアプリケーションの不具合が原因で、画面表示が乱れる。アプリケーションそのもののバグなので、問題のあるコードを修正する必要がある。開発者と適切なコミュニケーションを取って素早く解消することが、高得点を狙うポイントとなる。
