【ITニュース解説】What "Fully Automated" Actually Costs

システム開発の現場では、一度構築すれば後は自動で動き続ける「完全自動化」のシステムを夢見ることがよくある。しかし、現実にはそう簡単ではない。「何もしなくていい」と思われがちな自動化されたシステムも、実際には人間の介入が頻繁に必要となることがある。筆者は、誰も監視していないリモートマシンで自動システムを運用し、「受動的だ」と説明していたが、たった2日間で5回もの介入が必要になった経験を語る。これらの問題は特別なものではなく、ごくありふれた原因から発生し、自動化されたシステムを本当に「受動的」にするためには、こうした地味な問題に対処する設計が不可欠であると指摘する。

筆者が経験した五つの失敗は、どれもシステムが派手にクラッシュするような劇的なものではなく、静かに、そして気づかれにくい形で発生した。一つ目の失敗は、同じ処理が二つ同時に実行されてしまったことだった。本来これを防ぐための監視プログラムがあったにもかかわらず、それが比較する文字列の処理方法に問題があり、重複を検知できなかった。両方のプロセスはデータを書き込み続け、システムは何の異常も訴えなかった。二つ目は、システムが外部サービスとの認証情報を失ったケースである。サービス自体は動き続け、定期的に外部に問い合わせを行い、問題ないように見えたが、実際には認証されていないため、何の役にも立っていなかった。三つ目は、システムの一部のコンポーネントが、接続すべき本体から静かに切り離されてしまった事例だ。設定上は存在し、インストールもされていたが、機能的には分離されており、これもまたログには何も記録されなかった。四つ目は、書き込まれたファイルが、もはや誰も読まない状態になっていたことだ。ファイルを読み込むはずのコンシューマープロセスが数ヶ月前に停止しており、ファイルは正しく生成されるものの、誰にも消費されずに放置されていた。五つ目は、再起動後に設定がデフォルト値に戻ってしまったケースである。システムは再起動後も正常に稼働しているように見えたが、以前とは異なる動作をしており、その兆候はごくわずかな数値の違いでしか分からなかった。これらの失敗はすべて、人間が見てすぐに分かるようなエラーメッセージを出さなかったことが共通している。

これらの経験から、筆者はいくつかの重要な設計パターンを提唱している。 一つ目のパターンは、「再起動は状態変化であり、何もしないことではない」という考え方だ。私たちは再起動をシステムが既知の正常な状態に戻る行為と考えがちだが、実際には再起動それ自体が様々な失敗モードを伴う移行プロセスである。設定値がデフォルトに戻ったり、内部の識別子が再生成されたり、外部との接続が以前とは異なる順序で確立されたりすることがある。筆者は、起動シーケンス中に、外部サービスへの接続が認証される前にそのサービスから値を読み込んでしまい、その結果として誤ったゼロ値を正しい測定値としてシステムが利用し、三時間も間違った設定で稼働してしまった経験を挙げている。測定対象が存在する前に測定された値は、測定値ではなく、見せかけのデフォルト値に過ぎない。再起動後も確実に動作させるためには、再起動に耐える設計が必須であり、起動時に読み込むデータは「それが本当に利用可能になっているか」を必ず確認する必要がある。

二つ目のパターンは、「スケジュールされたジョブは完全に静かに失敗する」という問題への対処である。スケジュールされたタスクが停止しても、そのこと自体がシステムから通知されないことがよくある。例えば、筆者がディレクトリを移動した際、その変更に追随できない絶対パスで登録されていたスケジュールタスクが起動しなくなった。クラッシュしたプロセスは痕跡を残し、失敗したリクエストはステータスを返す一方で、スケジュールジョブが停止しても何も出力しない。これは、何もすることがない正常なシステムが出力する「何もない」状態と区別がつかないため、非常に危険である。この問題への対策として、スケジュールジョブは毎回実行時に「ハートビート」と呼ばれる生存信号を出力し、その信号が一定期間途絶えた場合にアラートを発するようにする。また、パスに依存する処理は、外部に保存された値ではなく、実行時に自身の位置を解決するようにすべきである。システムの健全性の唯一の証拠がエラーがないことであるならば、それは健全性の証拠とは言えない。

三つ目のパターンは、「エラーは『何も新しいことがない』ではない」と認識することだ。筆者のシステムでは、応答に何も含まれていなければ、メッセージループがスリープ状態に戻るようになっていた。しかし、トークンが失効した場合や、二重起動によって接続が奪われた場合、あるいはレート制限に達した場合なども、すべてエラー応答として返されるが、これらが「何も新しいことがない」状態と同一視されてしまい、システムは完全に機能停止しているにもかかわらず、プロセスは稼働し、監視システムも正常と判断していた。この対策として、応答の「内容」を確認する前に「ステータス」を必ず確認し、予期しないステータスは明確に異常として扱うべきである。また、ネットワーク呼び出しには必ずクライアント側でタイムアウトを設定し、「永遠に待つ」ことが「何もせずに生きているように見える」ことと同義にならないようにする。

四つ目のパターンは、「完了とマークする前に配信を確認する」という順序の徹底だ。筆者の通知システムでは、イベントが送信されたことを確認する前に、そのイベントをディスクから削除していた。結果として、送信が失敗してもイベントはすでに消えており、再試行も記録もなく、復旧する手立てもなかった。これは意図せず「最大一回配信（at-most-once delivery）」になってしまっていたが、本来は「最低一回配信（at-least-once delivery）」が求められる状況だった。通知の重複は煩わしいが、通知が届かないのは目に見えないため、はるかに悪い。この問題の解決策は単純で、順序を逆にするだけである。まず配信が成功したことを確認し、それから完了とマークするようにする。決してこの順序を逆にすべきではない。

五つ目のパターンは、「手動で監視できないマシンへのアップデート」を安全に行う方法である。これは最も設計に時間がかかった部分だという。その方法の形は以下の通りだ。 システムは外部からのプッシュではなく、自ら定期的にマニフェスト（更新内容を記述したファイル）をチェックし、更新を判断する「プル型」を採用する。更新適用前には、マニフェストに含まれる各ファイルのハッシュ値を検証し、不一致があれば拒否してアラートを出す。システムが作業中の場合は、更新を次の適用可能期間まで待機させる。作業を中断するような更新は、一日遅れる更新よりも害が大きい。更新適用後は、単にファイルが書き換えられたかではなく、実際に稼働しているプロセスから新しいバージョンが読み取れるかを確認して自己検証する。検証が失敗すれば自動的にロールバックし、アラートを出す。そして、新しいバージョンはまず一台のカナリアマシン（試験運用機）にのみ適用される。このカナリアマシンは常に開発者自身のマシンとし、更新によって問題が起きるならば、まず開発者自身がその影響を受けるようにする。

これらの経験から導かれる「正直なまとめ」として、筆者は自動化は「作業を取り除くものではなく、作業を移動させるものだ」と述べる。手動での作業はなくなるが、その代わりに「その作業を行うものを維持する」作業と、「それがまだ適切に機能しているかを知るための測定器を構築する」作業が発生する。この二番目の「測定器の構築」こそが、自動化のコストの大部分を占めるが、多くの人がこれを最初から見積もらない。筆者が今、何かを自動化する前に自問する質問は、「これは私がいなくても動くか」ではなく、「どの種類の失敗を、私は遅れて発見する準備ができているか」である。なぜなら、その準備ができていない失敗こそが、必ず発生するからだ。