倒れても自力で立ち上がろうとするインフラが好きなSREチームの川岡です。
サービスがダウンした時の応急処置くらいは自動化できないものかと思い、Cloud Pub/SubをトリガーにCloud FunctionsからCompute EngineへSSHでアクセスしてインスタンス上のアプリケーションを起動する検証をしてみました。
はじめに
コミューンではサービスの死活監視にGCPのCloud Monitoringを利用しており、エラーはSlackへ通知されます。
Documentationにはドキュメントを書くことができるので、復旧手順などを書いておくとメンバーのスキルに関わらず誰でも応急処置できて良いです。
サービスを起動する程度の応急処置であれば、人に頼らずGCPで完結できそうなので試してみました。
構成
今回の構成です。
以下の流れで応急処置します。
- Cloud Monitoringがエラーを検知するとCloud Pub/Subへ通知する
- Cloud Pub/SubがCloud Functionsの関数をトリガーする
- Cloud FunctionsがCompute EngineへSSHアクセスしてアプリケーションを起動する
設定
Cloud Pub/Subのトピックを作ります。
Cloud Pub/Sub > トピック > トピックを作成
設定はデフォルトで良いです。
作成トピックの名前をコピーしておきます。
Cloud Monitoringを設定します。
アラートの通知チャンネルへCloud Pub/Subを設定します。
Monitoring > アラート > MANAGE CHANNELS
ADD NEWからトピックを作成します。先ほどコピーしたトピック名を入力してチャンネルを追加します。
稼働時間チェックから監視設定を追加します。
監視対象を設定後、作成したトピックを選択すればMonitoringの設定は終わりです。
サービスアカウントへPub/Subトピックを公開する権限を設定します。
これを設定しないとダウン検知してもPub/Subトピックが発行されないためCloud Functionsが発火できません。
以下の部分です。
4. 通知サービス アカウントに、通知チャネルとして使用する各 Pub/Sub トピックを公開する権限を付与します。
最初の Pub/Sub チャネルを作成すると、Cloud Monitoring は、チャネルが作成されたプロジェクトの Monitoring Notification Service Agent 用のサービス アカウントを作成します。 このサービス アカウントは、このプロジェクトの通知チャネルへの Pub/Sub ベースでの通知の送信を管理します。
次にCloud Functionsで関数を作成します。
Cloud Functions > 関数の作成からトリガーのタイプにCloud Pub/Subを選び、作成したトピックを選択します。
今回はCloud Functions -> Compute Engine へ内部IPでSSHアクセスするのでVPCコネクタが必要です。
なければコネクタを作成から作成します。
SSHアクセスしてアプリケーションを起動するコマンドを記載したコードを書いてデプロイします。
今回はパスワード認証で検証しました。
動作確認
GCE上のアプリケーションを停止すると以下のようにチェックに失敗します。
なお、この稼働時間チェックはデフォルトで世界中の6つのリージョンから監視してくれます。（アメリカ3つ、アジア太平洋、ヨーロッパ、南アメリカ各1つずつ）
監視元のネットワーク不調が原因でサービスは正常にも関わらずアラートが出てしまう可能性がある監視よりも高い精度の監視が可能です。
Cloud Pub/Sub -> Cloud Functionsが実行されました。
応急処理が行われ復旧しました。
復旧優先で初手が決まっているトラブルシューティングであれば速やかに初動対応ができるので今回のような構成は有効かと思います。