迅速なフィードバックを得るためには、高い頻度で、準備が整えば即座にリリースし、自動化システムを使って変更をライブにテストすることが必要だ。正常に動作していること、警告が発生していないことの検証には、監視機能が使用できる。迅速なリリース(shipping fast)は結果的にテスト回数を削減し、問題に対するレジデンスを向上することになる。
Dan Abel氏はAginext.io 2020で、可観測性(observability)の適用から得た教訓について講演した。
小さな変更を日単位、時間単位でリリースすることは簡単に思われるが、十分に使いこなすのは難しい場合もある。しかしながら、独立性が高く、結合性の低いシステムを構築する上で大切なことだ、とAbel氏は言う。そのために必要なデザインについて、コーディング中も常に考えておくことが大切だ。
コンテキスト境界(Bounded Context)の概念(ドメイン指向設計のもの)は、分離や運用独立性の実現にはまず何をすればよいのか、ということを考える上で、優れた指針を与えてくれます。複数のサービスを同時にリリースする必要があるということは、テストやリリースや監視を行う方法に何らかの過剰な結合が存在している、というものもルールのひとつです。
製品やサービスを可能な限り早くリリースすれば、新たな気付きを得ることができる、とAbel氏は言う。"小さな問題であれば、確認も解決も比較的容易です。スケールアップする前に、よいパターンを学んでおくことが大切なのです。"
ソフトウェアエンジニア、コンサルタント、コーチのDan Abel氏に、迅速なリリースのための可観測性の適用についてインタビューした。
InfoQ: メトリクスや監視やダッシュボードは、どのような目的に役立つのでしょうか？
Dan Abel: Tesでは、システムのヘルスチェックに使用しています。システムが意図通り動作しているということ、さらに重要なのは、ユーザの目的を果たせているということについて、私たちに自信を与えてくれるのです。
私たちはアプリケーションに、メトリクス — 実行中のシステムからの情報収集を行う仕組みを織り込んでいます。それによってサービスの状態を、ダッシュボード上で可視化しているのです。重要なのは、モニタ上でこのデータを検証できることです。
私たちは、成功と失敗に関するメトリクスを追跡してシステムを検証すると同時に、モニタ経由で期待値を設定することで、成功値が低すぎたり、エラー数が上昇した場合に警告が発生するようにしています。
例えば、"PDFのレンダリングに支障があったのか？"、"ダウンロードは正常に提供できたのか？"というような確認が可能です。
私にとっては、これが運用時のテスト自動化なのです。
InfoQ: 少ないテストで迅速なリリースを実践している現在の会社に来た時、最初はどう思いましたか？
Abel: Tesに来た時には、この新しいやり方はエキサイティングな反面、課題も多いと感じました。統合スイートを実行せず、リリース前に隅々まで徹底したテストをしない、という方法が奇妙に感じられたのです。私の目的は新しいことを学んで、サービスのオーナシップを持ったエンジニアになることだったので、この課題を受け入れることにしました。
そして私は、求人申請システムのリプレースを構築するチームに参加することになりました。既存のシステムはビジネス上極めて重要なものだったので、リリースと習得を続ける新たな方法を見つけなくてはなりませんでした。
"素早く動いて破壊せよ(Move fast and break things)"は、ここではまったく当てはまりませんでした。リリースを続けるには、運用中のサービスから迅速かつ正確なフィードバックを得る必要があったのです。
そこで私たちは、"運用監視に関する知識を使って、テスト自動化の考え方を適用したらどうだろう？"と考えました。
その結果はもちろん — 私たちはエンジニアですから。システムが解析できたことで、さらに複雑な計測や監視が可能になったのです。
InfoQ: 迅速なフィードバック獲得のためには、どのようなことをしましたか？
Abel: 新たな開発を頻繁にリリースして、運用可能になったならば、ライブで自動化システムと組み合わせて、変更に問題がないことを確認します。
自動テストで十分なレベルの確信を得ることができたら、できるだけ早く、ソフトウェアをユーザの手に渡したいと思っているのです。カスタマサポートを通じてユーザからイシューが届くのを待つのではなく、システム上の自動化された目を維持することで、ユーザをサポートしています。
フィードバックには早さだけでなく、正確さも必要です。私の行った変更が、私たちのシステムを使ってユーザが自身の目的 — 例えば求人への応募 — を達成する能力にダメージを与えていない、ということを知りたいのです。そのために、システムが正常であることを検証し、そうでない場合は警告するような監視機能を構築しました。
迅速なフィードバックというパズルの最後のピースは、核心(nitty-gritty)、すなわち、"ユーザの要求に対して、私たちのコードがどのような動作をするのか？"を記録することです。問題が発生した時に、サービス内部で何が起きているのかを観察するための"のぞき穴"としてこのデータを使うことで、素早い対応ができるようになります。これは本当に役に立ちます。
InfoQ: どのようなスキルが新たに必要になって、どのように習得したのでしょうか？
Abel: 監視の観点からの考え方、監視ツールの詳細、監視の方法について学ぶ必要がありました。
大部分の監視システムは、プラットフォームやオペレーションの監視用にセットアップされています。それらを使ってアプリケーションを監視するのには、従来の利用以外の新たなエンジニアリングが必要になります。早い段階で、奇妙な部分がいくつも見つかりました。何も起きていないにも関わらず、障害が報告されるのです。今となっては笑い話ですが、必要な情報が得られるまで、監視システムの資料を何度も読み返していました。どのようなタイプのメトリクスや監視を使用するように設計するのが、という部分をさらに掘り下げることで、それまでよりも安定した監視システムを構築することが可能になりました。
当初の監視機能ではできなかったことで、私たちがやりたいことがある、ということも分かってきました。最初のアプリケーション監視機能には、誤報や通知ミスがたくさんありました。実際には発生していない問題を通知することが、非常に多かったのです。私たちは改善を続けました。
最終的には想定していた以上のコードを監視用に記述することになったのですが、それだけの価値は十分にありました。早い時期に必要最低限の監視システムを立ち上げて、実際の運用で使用することによって、本当に必要なものが分かったのです。
最終的に学んだスキルは、私たちはチームとして監視を続ける必要がある、ということでした。
計装、監視、可観測性といったものは、自動テストと同じように、場合によってはそれ以上に重要です。テストを管理する方法は、コードを管理する方法と同じように分かっていました。テストを管理する方法と同じように、運用性や可観測性を常に管理することを学ぶ必要があったのです。それはつまり、チームとしてレビューして、有効なものは維持し、スローダウンの原因になる陳腐な警告は削除ないし調整する、ということに他なりません。
InfoQ: どのような教訓がありましたか？
Abel: 迅速にリリースして、実際に起きていることに注意を払う、ということです。なぜか？ユーザによりよいサービスを提供できるからです。私たちのシステム構築方法にも大きく影響します。問題に対するレジリエンスを重視するようにもなりました。これは大きな収穫です。
運用システムのバグは避けられないものです。大きな問題が時折発生するのではなく、小さな問題が多数発生する、ということが分かってきました。このことから、何よりもまず、障害に対してシステムをよりレジリエントにすることを考えるようになりました。このような行動は、フィードバックがベースになることが多々あるため、システムの内部動作がもっと分かりやすくなるような視点の構築に努めるようになったのです。
システムを常にライブ状態で動作させるようにして、可能な限り早くユーザにローンチすると同時に、監視、学習、改善の計画を立てるようにしていくつもりです。
InfoQ: 他の人たちが同じ方法を採用するには、どうすればよいのでしょうか？
Abel: 大事なのは、持っているものを使い、必要なものを作ることです。
可観測性に関して、たくさんの書籍を読みました。最高に格好いい、本当にクールなニューテクノロジがいくつもありますし、最適なテクノロジに関する議論もたくさんあります。
こうした新技術はどれも本当にすばらしく見えますが、それが利用できないからといって諦めてはいけません。監査証跡をデータベースに記録して、例外的な動作を監視するだけでも、素晴らしい成果を得られるのです。重要なのは、ユーザのいる場所からのフィードバックの獲得です。適切かつ迅速な選択を行ってユーザを支援するために必要なフィデリティの確保に努めて、ユーザにとってより優れたシステムの構築を続けるようにしてください。