夜のよい睡眠に向けたエンジニアガイド

原文(投稿日：2019/08/20)へのリンク

私たちは本当に複雑な分散システムを構築しています。マイクロサービスの採用の増加は、アーキテクチャとインフラストラクチャが柔軟で短命であるクラウドへの移行によって加速されていますが、私たちが作成、維持するシステムに毎日複雑さを加えています。この複雑さはすべて、自律的で完全に権限を与えられたチームによる運用モデルと並行して行われるため、各分散システムでは、独自の技術的アプローチ、言語、サービスが複雑に絡み合っています。

ありがたいことに、このような複雑さにもかかわらず、完全に未開拓な方法で新しい世代のAPIを構築した経験から集めた一連のベストプラクティスを使用して、技術的に複雑ではあるがサポート可能なシステムを構築できます。

複雑さは柔軟性のコスト

画像：Skyscannerサービスのトレース

マイクロサービスは自律的で自己完結型であり、長期にわたるリリース調整に縛られることなく独立してデプロイできます。クラウドネイティブであるため、スケーリングの柔軟性が大幅に向上します。ただし、これらの新しいアプローチと技術的能力は、技術的な複雑さを軽減するためではなく、勢いを維持しながらチームをスケーリングするなどの組織上の理由で使用されます。そのため、これらにはすべて運用コストと複雑さの増大が伴います。

Martin Fowler氏は、マイクロサービスのトレードオフについて話します。

「運用の複雑さ: 多数のサービスを管理するには、成熟した運用チームが必要です。これらのサービスは定期的に再デプロイされています。」

Financial Timesで働いている間、私はチームが完全なグリーンフィールド方式でコンテンツAPIの新世代を構築するのを助ける機会がありました。この新しい機能をすべてをどのように再構築、デプロイ、保守するかを選択できる、自己組織化されたチームを作る権限を与えられました。技術スタックのすべての側面を選択できましたが、サポートモデルを定義する必要もありました。完全に説明責任があり、それを知っていたので、それを念頭に置いて構築しました。この説明責任により、運用サポートモデルを以前のプロジェクトとは異なる方法で見ることができました。

当初、私たちの実装は非常に不安定で、APIが定常的に利用できなかったり、さらに悪いことに、信頼できないデータを提供したりしていました。これにより、最初の主要な消費者であるft.comサイトの新しいバージョンは、APIがダウンした場合にキャッシュを使用してデータを保存することでサイトを保護しました。この新しいサイトの運用開始に至ったとき、彼らは私たちにアシュアランスサービスレベル契約（SLA）を求めました。

Financial Timesにとって最も重要なことは、ニュース速報です。そのため、ニュース速報に関係するAPIについては、15分間での回復という非常に厳しいSLAが求められました。現在、これは非常に困難です。特に、背後にかなり大きなデータストアがいくつかあるためです。このSLAには、一連の技術的な課題だけでなく、時間外のサポートなど、いくつかの組織的な課題も伴いました。幸いなことに、私たちは自分に最適なやり方でどうするかを定義することができました。私たちはそれを行い、時間外の電話を事実上排除することに成功しました。

私たちは、障害のない神話的で魔法のようなシステムを構築しませんでしたが、回復力のある技術的および運用的なシステムを構築しました。 5つのベストプラクティスにより、回復力を有するポイントに到達しました。

1. エンジニアを入れる

これは、最終的に回復力のあるシステムを構築する上で最も重要な部分です。すべてのエンジニアは、運用性を後付けとしてではなく、主要な関心事として考え始めなければなりません。彼らは継続的に実装に疑問を投げかける必要があります。「エラーが発生した場合、どうしたいですか。時間に関係なく呼び出されますか？再試行しますか？後で見るために何かを記録しますか（おそらく）？」

私たちは現在、少なくとも自立した、権限のあるチームになるべく取り組んでいます。このアプローチは説明責任を求められますが、採用したいサポートモデルへの影響も与えます。専任の全社的な第一線のサポートチームの従来のモデルで運用するのか、あるいはポケットベルのようなツールから直接呼び出されるチームで運用するのかは関係ありません。

もちろん、他のチームと連携することはプロセスを複雑にしますが、エンジニアからの圧力を取り除くこともできます。これはトレードオフであり、多くの場合、会社全体のモデルに依存します。チームは、最適な連携方法を定義し、適切なツールを使っていることを保証する必要があります。何よりも、チームが効果的に機能するためには、各チーム内および協力するチーム間の関係を促進および発展させる必要があります。

営業時間外のサポートの見直し

新しいサイトのロールアウトでコンテンツAPIのSLAが変更されたとき、時間外のサポートに関するコミットメントが必要でした。私たちはこの機会に、これを行う方法を調べました。私たちは、時間外のサポートが人々の家庭生活に与える影響を減らすことに熱心でした。次の図に示すように、2つのバケットのエンジニアを使用してこれを達成しました。

 
Financial Timesでコンテンツプログラムによって定義されたサポートモデル

運用チームは、バケット内のエンジニアにラウンドロビンコールを行うことができ、週によって1つのバケットが「待機中」になります。エンジニアは電話に出る義務がありませんでした。電話に出なければ、次の人が呼ばれます。これにより、人々は電話をかけることを心配することなく、自発的にパブに向かい、自転車に乗ったり、泳いだりすることができました。このシステムは完全に自発的であり、報酬が十分に支払われていたため、電話に出て残業する人々もいました。一部の人々はこれにコミットできないことを認識することが重要です。また、これが日々の仕事ではないことを認識することも重要であり、給与が支払われるべきです。

このサポートモデルは日中にも拡張されました。インシデント、問い合わせに対応し、さらにプラットフォームと運用プロセスの改善に取り組んだ2人の人がいました。彼らはエンジニアリングチームから交代で参加しました。これは専用の役割でした。それは、重要な機能であり、スケジュールされた作業を行っていた場合、運用上の改善は行われないと認識していたためです。さらに、これはエンジニアが慣れ親しんでいるエリアだけでなく、資産全体でプルリクエストを提起することを意味していました。このプラットフォーム全体に対する問題処理は重要な側面でした。これにより、数時間の電話に対応できるというエンジニアの自信につながり、エンジニアがビジネス機能を実装する際の運用上の懸念について考えるようになりました。悪いプラクティスの痛みは、午前3時にローテーション中に、彼らを噛みつき、さらに悪化することもあるでしょう。

自分のコードが時間外の呼び出しにつながる可能性があることを理解している場合、人々はシステムを異なる方法で設計します。「このエラーはビジネスに影響しますか？」 Financial Timesにとって、質問は常に「このエラーはブランドに影響を与えますか？」でした。 しかし、病院や発電所で働いていた場合、そのビジネスはさらに悪化する可能性があります！

エラー処理

次の改善点は、エラーを捕獲し、適切な方法で警告することです。 重大度レベルについて考えることは、通常の時間内に修正できるものを区別するための便利なツールです。 すべてのエラーがシステムの主要な機能に問題を引き起こすわけではありません。採用したものの例を次に示します。

重大度レベルは、集約されたシステムヘルスチェックに明確に記載されています。

コンテナ化されたプラットフォームがあり、Kubernetesに移行する前は、手作業から始めていました。プラットフォームがコンテンツの公開などの重要なビジネスアクティビティを実行できなかった場合、すぐに理解したかったのです。しかし、数時間で復旧できるサービスが余暇の時間には「機能していない」ことがいくつかありました。上記の例は、プラットフォーム全体のヘルスを集約したヘルスチェックページを示しており、集約がクリティカルになった場合に呼び出されました。ただし、示されている例では、使用しているコンテナオペレーティングシステムであるCoreOSの古いバージョンがあることを警告しています。この警告には、重要なセキュリティパッチが含まれている可能性があるため、対処することが非常に重要でした。ただし、日曜日の午前3時に実行する必要はありません。代わりに月曜日にコーヒーの後に対処することで問題ありません。

エンジニアは、今後の運用上の問題に対処するだけでなく、運用方法が改善されると、古いアプリケーションを一目見たり更新したりすることができます。

ソフトウェア進化に関するリーマンの法則は次のように述べています。

「システムの品質は、綿密に維持されない限り低下しているように見えます。」

「システムが進化するにつれて、システムを維持または削減するための作業を行わない限り、システムの複雑さが増します。」

これは、技術的な実装と運用サポートモデルに適用できます。エンジニアは、必要に応じて機能を維持するために、システムの運用面を維持および強化する必要があります。

2. 営業時間内の電話をより多くとり、営業時間外の電話を避ける

これはおそらく最大のカテゴリであり、時間外通話に対する責任に関連します。ただし、この可能性を減らすためにできることがいくつかあります。

リリース

リリースは最大の容疑者です。世界で最高の意志があったとしても、問題のないリリースを完全に保証することはできません。シナリオは発見されないままになる可能性があります。問題のゆっくりとした「リーク」は、数時間、数日、数週間にわたってより顕著になります。リリースは常に電話される可能性を高めますが、そのリスクを減らすためにいくつかのことができます。

午後5時にリリースしないというのは解決策ではありません。遅めのリリースに対する恐怖は、おそらく、リリースやリリースをサポートするチームに対する自信が低いことを示す良い指標です。もちろん、リスクのバランスは常にあります。

• リリースの影響は何ですか？
• これはどれくらい早くロールバックできますか？
• このリリースで問題が起こらないと確信していますか？

Charity Majors氏はこれについてブログに投稿し、金曜日のフリーズを「子犬の殺害」に例えています。

@mipsytipsyによるブログ投稿「金曜日のデプロイ禁止はまさに殺人の子犬のようです」

デプロイは可能な限り迅速にする必要があります。人々の注目期間を過小評価しないでください。時間がかかる場合、リリースを検証する前に、人々は出かけてお茶を飲むか、さらに悪いことに、家に帰ってしまいます。デプロイを非常に高速にできない場合は、リリースが正常に終了したことを検証するために確実につついてください。CIにフックされた単純なSlackアラートで十分です。あるいは、検証を自動化してもかまいません。

本番稼働後は、何らかの方法で検証することが重要であり、必ずしも高度である必要はありません。これは、実稼働環境でのテストを意味します。これは、言うほど怖くありません。誰もが自分のコードを本番環境に投入し、それが最高の結果となることを期待しているわけではありません。いくつかのオプションがあります。

• 本番環境の詳細を把握し、手動テストを実行できる
• 最初に変更にさらされた少数のユーザで機能フラグを使用する
• リリースに自信を持ちながら、一晩で新機能をオフにする
• リクエストを常にリプレイして、早期に問題をハイライトする

James Governor氏はこれを「プログレッシブデリバリ」と呼び、Cindy Sridharan氏は本番環境でのテストについても語っています。

リリースに加えて、他に夜間バッチジョブの途中で電話をかける可能性を大幅に高めることがあります。

バッチジョブ

深夜に高負荷なバッチジョブを使用すると、問題のフィードバックが遅れてしまいます。まさにあなたがそれを望まない時となっていまいます。

次の図はこれを示しています。

リアルタイムの注文を受け取り、午前3時に注文を変換する注文システム

ここに、イベント駆動型の方法で注文を取得するシンプルな注文システムがあります。ただし、サードパーティの照合にファイルを送信する前に、午前3時にすべての注文を集約して変換します。

重い計算の多くを日中に戻すことができる場合、以下に示すように、コールを営業時間に戻します。

変換処理をリアルタイムに移行する改善された注文システム

そのため、リアルタイムで注文を変換または集約した場合、午前3時にジョブを実行すると、ファイルをFTPで第三者に送信するだけで済みます。

3. 可能な限り障害回復を自動化する

コンピューターがあなたのためにできることで目覚めないでください。コンピューターはとにかくよりよい状況にしてくれます。

自動化の点で私たちの方法を実現するために最良のことは、私たちが現在持っているすべてのクラウドツールとアプローチです。サーバレスであろうとコンテナであろうと、どちらも以前は手作業で処理しなければならなかったスケーラビリティの自動化を実現します。

Kubernetesはサービスのヘルスチェックを監視し、オンデマンドで再起動します。また、「計算」が利用できなくなったときにサービスを移動します。サーバレスはリクエストを再試行し、クラウドプロバイダのアラートシステムにシームレスに接続します。

これらのプラットフォームは長い道のりを歩んできましたが、それでも私たちが書いたアプリケーションと同じ程度です。私たちはそれらがどのように実行され、どのように自動回復されるかを理解してコーディングする必要があります。

人間なしで回復できるアプリケーションを開発する

アプリケーションに次の特性があることを確認します。

• 正常な終了: アプリケーションを終了することは、例外ではなく標準であると見なすべきです。Kubernetesクラスターのノードを失った場合、Kubernetesは別のVMでアプリケーションをスケジュールする必要があります。
• トランザクショナル: アプリケーションがいつでも失敗し、中途半端なデータを引き起こさないことを確認します。
• クリーンな再起動: クラウド内のVMが失われることが保証されており、これに耐える必要があります。新しい機能が起動するか、コンテナが移動されるかです。
• キューのバックアップ: 突然終了した場合、アプリケーションが中断したところから再開できるようにする1つの方法として、キューを介してアプリケーションをバックアップします。
• べき等性: これは、繰り返されるリクエストの結果が同じになることを意味し、失敗したイベントを再生できるために非常に便利です。
• ステートレス: ステートレスマイクロサービスは簡単に移動できます。そのため、可能であれば、それらをステートレスにします。

完全なシステム障害の可能性を許容

停止が1つのサービスよりも大きい場合や、停止の規模がまだわかっていない場合に対処するための手法もあります。そのような手法の1つは、プラットフォームを複数のリージョンで実行することです。そのため、あるリージョンで問題が発生した場合、別のリージョンにフェイルオーバーできます。

たとえば、Financial Timesでは、ACTIVE/ACTIVEのセットアップがあり、以下に示すように、クラスタ全体がEUとUSの両方で実行され、リクエストはいずれかのクラスタに地理的なロケーションのルーティングがされました。

ACTIVE/ACTIVEマルチリージョンフルシステム展開

また、各クラスターのヘルスチェックを集約し、いずれかがクリティカルになった場合、すべてのトラフィックを他のクラスターに転送します。復旧時に、両方からのサービスに自動的にフェイルバックします。 ACTIVE/PASSIVEセットアップがある場合、フェールバックオプションに状態回復/検証のスクリプトを作成する必要がある場合があります。

4. 顧客の関心事を理解する

顧客が本当に気にしていることを理解することは、始めに考えるような簡単なものではありません。なぜなら、顧客に尋ねると、彼らは「すべて」と言うからです。ただし、ドメインを理解すると、特定の機能の重要な性質を理解し始めます。たとえば、Financial Timesの場合、彼らのブランドは非常に重要であり、それにリンクすることがニュースを公開するために必要なため、コンテンツプラットフォームに取り組んでいる間、出版物とコンテンツを読む能力を重要と見なしました。

重要なフローを理解したら、顧客の前に問題がいつ発生するかを知る必要があります。顧客を、停止や問題を私たちに知らせる人にしてはいけません。重要なフローについては、他のノイズなしで確実にアラートを送信するようにしたいでしょう。

「対処する必要があるアラートのみを受けたいです。」 - Financial Timesの運用および信頼性担当ディレクターのSarah Wells

「アラート疲労」とは、すべてのエラーについてアラートを出すと、それらのアラートをほとんど見えなくしてしまうことを意味します。すぐにアクションを起こすものについてのみアラートを受けます。たとえ、そのアラートに対するプランが何もないエラーであっても、そのアラートがシステムにとって重要になったときに将来それらに対処できるためです。修正したい場合は、これらの未警告の問題について将来クエリできるログがあります。結局のところ、完璧なシステムというものはありません。

すべてのアプリケーションが同等というわけではありません。以前に特定したフローに影響を与えるビジネスに不可欠なアプリについてのみ警告します。電話が必要なものもあれば、翌日にオフィスでコーヒーを飲むまで待てるものもあります。

アラートを設定するのは素晴らしいことですが、アラートを送信する実際の失敗まで待つ必要は必ずしもありません。これは、トラフィックが急増する場合に特に当てはまります。コンテンツプラットフォームはこれの実に素晴らしい例です。 Financial Timesはグローバルですが、ほとんどのコンテンツはUK内で作成されているため、日曜日の早い時間帯にはほとんど出版者がいません。そのため、この状況は「シュレディンガーのプラットフォーム」を示しています。プラットフォームは死んでいるのでしょうか、それとも出版されていないのでしょうか？

重要なフローに関するフィードバックの安定した流れを確保するために、人工リクエストと呼ばれるものを導入しました。または、システムを通じて継続的に送られたコンテンツの再発行を単に行いました。これにより、実際のパブリッシュに関係する何かに問題があった場合にアラートを出すことができました。

これらの人工リクエストにより、驚くべき追加の利点が得られました。モニタリングとこれらの人工リクエストをより低い環境にデプロイしたため、実際にはエンドツーエンドのテストとしてモニタリングを使用することになりました。

トランザクション識別子を埋め込むだけで、初歩的なトレースでコードを計測しました。現在、より豊富なトレース情報を提供できるZipkin などのツールが多数あります。Ben Sigelman氏は、QCon London 2019で、トレースの重要性に関する素晴らしい基調講演「マイクロサービスの信頼の回復：トレースを超えるトレース」を行いました。

このトレースにより、システムを介してパブリッシュを追跡し、ラインに沿ってどこかにスタックしたときに反応することができました。私たちは最初に監視を行うサービスを作成しましたが、非常に不安定になり、システム全体に分散した多くのビジネスロジックを理解する必要がありました。これは、マイクロサービスの世界ではアンチパターンのように思えました。そのため、構造化されたログを使用して監視イベントを特定する方向に進みました。次に、これらのログをKinesisに与え、以下に示すように、結果に対してストリーミングSQLを実行できました。

kinesisストリームでのストリーミングSQLを使用したログの分析

このアプローチは、「特定の時間枠内にすべての期待される結果を得たか」と尋ねられることを意味しました。

5. 問題を起こして練習する

以前のベストプラクティスを実行した後、電話がかからないようにできる限りのことを行ったように見えますが、他のすべてが失敗して午前3時に電話がかかったらどうしますか？

「カオスエンジニアリングとは、乱流や予期せぬ状況に耐えるシステムの能力に自信を持たせるために、本番環境でソフトウェアシステムを実験することです。」

私たちは、断片を抜き出したり、ダウンさせたりすることで、システムが障害に対してどれほど回復力があるかをテストできます。これはシステムレベルで実行できますが、運用サポートの人的要素のテストにも非常に役立ちます。

いつカオスモンキーを解放すべきですか？誰もがシステムの成熟の旅の異なる地点にいるので、答えはそれによって異なります。ただし、モノリスからマイクロサービスへの移行のかなり一般的な旅をしている場合、いつから実験を開始しますか？モノリスがまだあるときは、システム全体をダウンさせるため、明らかにこれを行うことはできません。ただし、このスタイルの実験を行うために旅の最後に来るまで待つ必要はないと思います。同様に、そのような実験から価値を得るために自動化されたものや精巧なものを実装する必要はありません。サービスまたはVMを手動で停止し、システムがどのように反応するかを確認できます。

システムのサポートを練習する他の方法もあります。Financial Timesのコンテンツプラットフォームでは、以下に示すように、パブリッシュのエントリで単一障害点がありました。

Financial Timesのコンテンツプラットフォームの簡易ビュー

この単一障害点は間違いなく修正したかったものですが、その影響は非常に広範囲に及んでいたため、なんらかの努力をすることができませんでした。それはまた、あなたが期待するほどの痛みを引き起こさないものでもありました。実際にはいくつかの利点がありました。更新プログラムをリリースする場合、リリース中に他のリージョンにフェールオーバーする必要があります。

したがって、実際には、定期的にフェールオーバーを実行していました。緊急のサポートプロセスのメカニズムに依存している場合は、定期的にそれを実行し、それが機能し続けることを確実にし、またこれを行うことに関する不安と不確実性を減らすようにしてください。以下のような習慣に従うことは、夜のよい睡眠のための最善の策です。

• 電話をすることの意味を理解するチームを構築する。そして、システムを所有するにつれて、サポートのすべての側面も所有します。
• 開発プロセスがベストプラクティスに従っていることを確認して、標準的な昼間のアクティビティから電話が引き起こされるリスクを減らします。
• 障害回復の自動化はますます簡単になりつつあるため、可能な限り活用します。
• 顧客のニーズを深く理解することは、障害にすばやく対応できることを意味します。
• あなたの反応をテストするために致命的な失敗を待たないでください。あなたのサポートのあらゆる側面をテストするために使用できるプロセスとアプローチを配置してください。

定期的に練習することで、システムをサポートする自信が高まります。これにより、午前3時に電話がかかった場合の対処方法を知る自信が高まります。

著者について

Nicky Wrightson氏は現在、世界の旅行検索エンジンであるSkyscannerのデータプラットフォームに取り組んでいるプリンシパルエンジニアです。その前は、Nickyはメディア組織であるFinancial Timesのプリンシパルエンジニアとして働いていました。ここで、彼女はオペレーションモデルを刷新した新しいコンテンツおよびメタデータプラットフォームの展開を指揮しました。彼女は、新しいクラウドネイティブアーキテクチャの作成だけでなく、必要な文化的進化にも変化をもたらすことに情熱を傾けています。