すべての変更において、一部のコンテンツは同じままです。これらの質問は、最小限のワークロードと無停止の方法でコードを本番環境にデプロイする方法です。次に、サービスが正常に実行されているかどうか、実行中か閉じているかをどのように知ることができますか。また、正しく構成した場合、サービスは期待どおりに動作しますか？
展開プロセスを改善するために、どの環境でも実行できる4つの簡単なことを次に示します。これらにより、アプリケーションを正しく実行および構成するためのより良い洞察と自信が得られます。
アプリケーションヘルスチェック
アプリケーションの展開と管理を改善するための最初のステップは、アプリケーションが正しく機能しているかどうか（実行中であり、期待されるタスクを実行できるかどうか）を理解し、ダウンストリームサービスと通信して、正しいバージョンを実行できるかどうかを理解することです。明らかに、監視は重要ですが、私たちの監視方法は、自動展開にそれを使用するための鍵です。私が働いたすべての場所で、アプリケーションとデータベースの何らかの形の監視を実行しましたが、すべての人がアプリケーションのヘルスチェックを実行したわけではありません。
最近、Kountableでは、すべてのアプリケーションに/ public / healthポイントを設定しました。このヘルスチェックは、アプリケーションについて教えてくれます。まず、アプリケーションが正常に実行されているかどうか（起動して準備ができているか）。次に、アプリケーションが実行しているコードのバージョン（commit）。第三に、アプリケーションの稼働時間、そして最後にconnection_status。connnection_statusは、アプリケーションがデータベースまたは下流のサービスに接続できるかどうかを教えてくれる。そうでない場合は、これがネットワークの問題なのか、パスワードの問題なのか、ダウンストリームサービスのオフラインの問題なのかを確認できますか？これにより、アプリケーション障害の時間と焦点を減らすことができます。これはヘルスチェック出力の例です。
{
"healthy": true,
"commit": "1e98e46",
"uptime": "05:22:47:21",
"connection_status": true
}このヘルスチェックは、サービスを監視するためだけでなく、展開プロセスの一部としても使用できます。ヘルスチェックを使用して、インストールされているバージョン（commit）と、青緑色の展開中のヘルスおよび接続ステータスを確認できます。これらすべてに加えて他の包括的なテストに合格すると、デプロイメントを本番環境に自動的にアップグレードできます。
このセットアップの初期には、ヘルスチェックに失敗したサービスをAWSECSにデプロイしました。送信IDが展開するIDと一致しません。すでにECSサービスを実行している場合は、AWSがその仕事をうまく実行できることを知っています。これにより、現在実行中のサービスへの影響を最小限に抑えて、新しいバージョンのECSタスクを展開できます。ECSは新しいタスクを開始し、ターゲットグループで構成されたヘルスチェックエンドポイントを確認し、合格した場合にのみ、古いタスクを使い果たして新しいサービスを有効にします。過去に、多くの新しいECSタスクが展開されているのを見てきましたが、それらは常に起動と失敗のサイクルにあります。タスクの展開にAWSエラーはありません。唯一のオプションはCloudWatchログを表示することであり、サービスが毎分開始および停止するのがわかります。時間がかかる場合があります
送信IDまたはバージョンを使用したアプリケーションのヘルスチェック、および青緑色の展開を通じて、展開の失敗を検出できます。展開ツールは、展開する送信IDとヘルスチェック送信IDを確認します。それらが一致しない場合、展開は停止します。この単純な設定により、問題を特定するために30分以上の時間が節約され、問題が本番環境に移行するのを回避できます。
イベントノート
私が何度も見た傾向の1つは、システム、アプリケーション、または環境に変更がない場合、問題や中断はほとんどないということです。私がApigeeで働いていたとき、初期の頃、お客様は急速に成長し、コードは継続的にリリースされていました。急速な開発と継続的な展開のこの期間中に、本番アプリケーションで多くの問題が発生します。静かな時期に、実稼働環境がない場合、問題はほとんどなくなるか、ほとんどなくなります。
絶えず変化する環境では、すべての変化を追跡することは困難です。変更が発生した場合、特に変更が時間の経過とともにグローバルに展開される場合は、範囲を狭めるのに時間がかかります。実装が簡単で非常に役立つと思うことの1つは、変更イベントをログに記録して、監視システムに追加することです。これは、展開ツールを使用して簡単に実行し、展開イベントで監視システムを更新できます。
これは、最近アプリケーションをデプロイし、応答時間がすぐに増加した例です。grafanaアノテーションは展開時間をマークし、応答時間のピークが表示されます。
原因をすばやく特定するのに役立つだけでなく、実装が簡単な展開プロセスやその他の自動化されたプロセスの記録されたイベントも見つかりました。環境へのすべての変更（構成管理ツール、パッチ適用、バックアップ、さらには非自動変更から実行）を変更する必要があると思います。
バックアップイベントを追加すると、バックアップウィンドウをシステムリソースの使用量（CPU、メモリなど）にオーバーレイするのに役立つことがわかりました。これは、バックアッププロセスがCPUとメモリのスパイクの原因であるかどうかをすばやく簡単に確認する方法です。
ポッド：影響を最小限に抑える
データセンターの設計、VMwareポッドからKubernetesポッドまで、ポッドの概念にはさまざまな反復があります。ポッドを使用または設計する方法はたくさんあります。重要なのは、一部のコンポーネント、顧客、またはサービスに対する障害の影響を軽減するようにアプリケーションとインフラストラクチャを設計することです。
Apigeeでアプリケーションとインフラストラクチャを一緒に設計したとき、私たちはこの概念を実現しました。運用面でエンジニアリングと協力して、2つ以上のアプリケーションポッドで顧客を実行するマルチテナントアプリケーションを設計しました。私たちにとって、ポッドはアプリケーションサービスのセットであり、1〜X人の顧客が特定のポッドに割り当てられます。たとえば、コアアプリケーション用のポッドと、分析またはロギング用の別のポッドがあるとします。AWSの設定では、AWSリージョンごとにアプリケーションポッドを作成してから、世界のすべてまたは複数のリージョンのポッドに顧客を割り当てることができます。
クラウドの障害、展開の問題、またはその他の要因により、特定の領域のポッドに問題がある場合。この問題の影響は、このエリアのポッドの顧客にのみ限定されます。通常、顧客を複数の地域に展開した後は、問題に気付くことはありません。
アプリケーションとインフラストラクチャを一緒に設計することにより、問題/爆風半径の影響を減らす可能性が高くなり、最終結果が向上します。
青緑色の展開
青緑色の展開では、2つの異なるバージョンのアプリケーションを実行し、1つはリアルタイムトラフィックを実行できます。いくつかの異なる方法で設定できます。過去に、ECSで2つのバージョンのアプリケーションを実行しましたが、どちらも同じデータベースを指しています。
アプリケーションとデータベースは、順方向および逆方向に互換性がある必要があります。互換性の鍵は、データベーススキーマの変更です。どちらのバージョンでも必要になるまで、列の削除を延期する必要があります。
v1.0.3またはv1.0.5を切り替えるために、AWS ALBは2つのルールを設定します。1つは青用、もう1つは緑用です。ALBは、リスナールールを青から緑に切り替えてから、古い（青）接続をすべて使い果たします。
私たちに関しては
Zeyang、認定ジェンキンスエンジニアDevOpsフィールドプラクティショナー。エンタープライズレベルのDevOps運用および保守開発技術の実践の共有に焦点を当て、主に新しいLinux運用および保守技術とDevOps技術コースに焦点を当てます。豊富な最前線の実践経験、コースでの実用性の追求は、ほとんどの学生に認められています。コースの内容は、テクノロジーを学ぶだけでなく、人気のあるスキルを習得できるエンタープライズアプリケーションからのものです。大歓迎です。