クラウドネイティブ アプリを構築するための 5 つの常識原則

「クラウド ネイティブ」または単に「クラウド」アプリケーションは、特にクラウド インフラストラクチャで動作するように作成されています。これらは通常、コンテナーにパッケージ化された疎結合マイクロサービスのセットとして構築され、クラウド プラットフォームによって管理されます。このようなアプリケーションはデフォルトで障害対応となっており、インフラストラクチャ レベルの重大な障害が発生した場合でも確実に動作し、拡張可能です。コインの裏側は、コンテナ アプリケーションを自動的に管理できるようにするために、クラウド プラットフォームがコンテナ アプリケーションに課す一連の制限 (契約) です。

多くの組織は、クラウドベースのアプリケーションに移行する必要性と重要性を十分に認識していますが、どこから始めればよいのかまだわかりません。この投稿では、コンテナ化されたアプリケーションを開発する際に従えば、IT インフラストラクチャで重大な障害が発生した場合でも、クラウド プラットフォームの可能性を実現し、アプリケーションの信頼性の高い運用とスケーリングを実現できるようになる多くの原則を見ていきます。レベル。ここで概説する原則の最終目標は、Kubernetes などのクラウド プラットフォームで自動的に管理できるアプリケーションを構築する方法を学ぶことです。

ソフトウェア設計原則

プログラミングの世界では、原則とは、ソフトウェアを開発する際に従わなければならないかなり一般的なルールを指します。これらは、任意のプログラミング言語を使用するときに使用できます。それぞれの原則には独自の目標があり、それを達成するためのツールは通常、テンプレートと実践です。高品質のソフトウェアを作成するための基本原則も多数あり、そこから他のすべての原則が生まれます。基本原則の例をいくつか示します。

• KISS （単純にしてください、愚か者） – 複雑にしないでください。
• DRY （同じことを繰り返さないでください） - 同じことを繰り返さないでください。
• ヤギ (必要になるわけではありません) - すぐに必要でないものは作成しないでください。
• SoCの 関心事の分離 – 責任を共有します。

ご覧のとおり、これらの原則は特定のルールを定めているわけではありませんが、実務経験に基づくいわゆる常識的な考慮事項のカテゴリーに属しており、多くの開発者が共有し、定期的に参照しています。
また、 SOLID – Robert Martin によって定式化された、オブジェクト指向プログラミングと設計の最初の XNUMX つの原則のセット。 SOLID には、広範で制限のない補完的な原則が含まれており、これらを組み合わせて適用すると、より優れたソフトウェア システムを作成し、長期にわたってより適切に維持するのに役立ちます。

SOLID 原則は OOP の分野に属し、クラス、インターフェイス、継承などの概念や概念の言語で定式化されます。同様に、開発原則はクラウド アプリケーションに対しても定式化できます。ここでの基本要素はクラスではなくコンテナだけです。これらの原則に従うことで、Kubernetes などのクラウド プラットフォームの目標と目的をより適切に満たすコンテナ化されたアプリケーションを作成できます。

クラウドネイティブコンテナ: Red Hat のアプローチ

現在、ほとんどすべてのアプリケーションを比較的簡単にコンテナにパッケージ化できます。しかし、Kubernetes のようなクラウド プラットフォーム内でアプリケーションを効果的に自動化し、オーケストレーションするには、さらなる努力が必要です。
以下に概説するアイデアの基礎となったのは方法論です。 Twelve-Factor アプリ 他にも、ソース コード管理からモデルのスケーリングに至るまで、Web アプリケーション構築のさまざまな側面に関する多くの研究を行っています。ここで説明する原則は、マイクロサービス上に構築され、Kubernetes などのクラウド プラットフォーム向けに設計されたコンテナ化されたアプリケーションの開発にのみ適用されます。ここで説明する基本要素はコンテナー イメージであり、ターゲット コンテナー ランタイムはコンテナー オーケストレーション プラットフォームです。提案された原則の目標は、ほとんどのオーケストレーション プラットフォーム上でタスクのスケジューリング、スケーリング、監視を自動化できるコンテナを作成することです。原則は順不同で説明します。

単一懸念原則 (SCP)

この原則は多くの点で単一責任原則と似ています。 SRP)、これは SOLID セットの一部であり、すべてのオブジェクトが XNUMX つの責任を持つ必要があり、その責任はクラス内に完全にカプセル化されなければならないと規定しています。 SRP のポイントは、すべての責任が変化の理由であり、クラスには変化の理由が XNUMX つだけ存在する必要があるということです。

SCP では、OOP クラスと比較してコンテナのより高いレベルの抽象化とより広範な目的を示すために、「責任」という言葉の代わりに「懸念」という言葉を使用します。そして、SRP の目標が変更の理由を XNUMX つだけにすることである場合、SCP の背後には、コンテナの再利用と置き換えの機能を拡張したいという願望があります。 SRP に従って、単一の問題を解決し、機能的に完全な方法で実行するコンテナーを作成すると、そのコンテナー イメージをさまざまなアプリケーション コンテキストで再利用できる可能性が高まります。

SCP の原則では、各コンテナは XNUMX つの問題を解決し、それを適切に実行する必要があると規定されています。さらに、コンテナ世界の SCP は、OOP 世界の SRP よりも達成が簡単です。これは、コンテナは通常 XNUMX つのプロセスを実行し、ほとんどの場合、このプロセスが XNUMX つのタスクを解決するためです。

コンテナー マイクロサービスが複数の問題を一度に解決する必要がある場合は、サイドカー テンプレートと init コンテナー テンプレートを使用して、マイクロサービスを単一タスクのコンテナーに分割し、XNUMX つのポッド (コンテナー プラットフォーム デプロイメントの単位) 内で組み合わせることができます。さらに、SCP を使用すると、古いコンテナ (Web サーバーやメッセージ ブローカーなど) を、同じ問題を解決しながら機能が拡張されたり拡張性が向上した新しいコンテナに簡単に置き換えることができます。

高可観測性の原則 (HOP)

アプリケーションをパッケージ化して実行するための統一された方法としてコンテナーが使用される場合、アプリケーション自体はブラック ボックスとして扱われます。ただし、これらがクラウド コンテナーの場合は、コンテナーの状態を監視し、必要に応じて適切なアクションを実行するために特別な API をランタイムに提供する必要があります。これがなければ、コンテナの更新とライフサイクル管理の自動化を統合することができず、その結果、ソフトウェア システムの安定性と使いやすさが悪化します。

実際には、コンテナ化されたアプリケーションには、少なくとも、ライブネス テストや準備テストなど、さまざまな種類のヘルス チェック用の API が必要です。アプリケーションがそれ以上のことを行うと主張する場合は、その状態を監視する他の手段を提供する必要があります。たとえば、Fluentd、Logstash、およびその他の同様のツールを使用したログ集約のために、STDERR および STDOUT 経由で重要なイベントをログに記録します。 OpenTracing、Prometheus などのトレースおよびメトリクス収集ライブラリとの統合も可能です。

一般に、アプリケーションは依然としてブラック ボックスとして扱うことができますが、可能な限り最善の方法で監視および管理するためにプラットフォームが必要とするすべての API をアプリケーションに提供する必要があります。

ライフサイクル適合原則 (LCP)

LCP は HOP の対極です。 HOP では、コンテナーが読み取り API をプラットフォームに公開する必要があると規定されていますが、LCP では、アプリケーションがプラットフォームから情報を受け入れることができる必要があります。さらに、コンテナはイベントを受信するだけでなく、イベントに適応、つまり反応する必要もあります。したがって、この原則の名前は、プラットフォームに API の書き込みを提供するための要件と考えることができます。

プラットフォームには、コンテナーのライフサイクルの管理に役立つさまざまな種類のイベントがあります。ただし、それらのどれを認識し、どのように反応するかを決定するのはアプリケーション自体次第です。

一部のイベントが他のイベントよりも重要であることは明らかです。たとえば、アプリケーションがクラッシュをあまり許容しない場合は、signal: terminate (SIGTERM) メッセージを受け入れ、できるだけ早く終了ルーチンを開始して、SIGTERM の後に来る signal: kill (SIGKILL) をキャッチする必要があります。

さらに、PostStart や PreStop などのイベントは、アプリケーションのライフサイクルにとって重要な場合があります。たとえば、アプリケーションを起動した後、リクエストに応答するまでにウォームアップ時間が必要になる場合があります。または、アプリケーションはシャットダウン時に特別な方法でリソースを解放する必要があります。

画像不変原則 (IIP)

コンテナ化されたアプリケーションは、異なる環境で実行される場合でも、構築後は変更されないことが一般的です。そのため、実行時にデータ ストレージを外部化する (つまり、そのために外部ツールを使用する) 必要があり、環境ごとに固有のコンテナを変更または作成するのではなく、外部の実行時固有の構成に依存する必要があります。アプリケーションに変更を加えた後は、コンテナー イメージを再構築して、使用されているすべての環境にデプロイする必要があります。ところで、IT システムを管理する際にも、サーバーやインフラストラクチャの不変性の原則として知られる同様の原則が使用されます。

IIP の目標は、異なるランタイム環境に対して個別のコンテナー イメージが作成されるのを防ぎ、適切な環境固有の構成とともにどこでも同じイメージを使用できるようにすることです。この原則に従うことで、アプリケーション更新のロールバックやロールフォワードなど、クラウド システムの自動化の観点から重要なプラクティスを実装できます。

プロセス使い捨て原則 (PDP)

コンテナの最も重要な特性の XNUMX つはその一時性です。コンテナのインスタンスは作成も破棄も簡単なので、いつでも簡単に別のインスタンスに置き換えることができます。このような置き換えには、保守性テストの失敗、アプリケーションのスケーリング、別のホストへの転送、プラットフォーム リソースの枯渇、その他の状況など、さまざまな理由が考えられます。

その結果、コンテナ化されたアプリケーションは、何らかの外部手段を使用して状態を維持するか、そのために冗長性のある内部分散スキームを使用する必要があります。さらに、アプリケーションは迅速に起動して迅速にシャットダウンし、突然の致命的なハードウェア障害に備えなければなりません。

この原則の実装に役立つ XNUMX つの実践方法は、コンテナーを小さく保つことです。クラウド環境では、コンテナ インスタンスを起動するホストを自動的に選択できるため、コンテナが小さいほど起動が速くなります。ネットワーク経由でターゲット ホストにコピーするだけで高速になります。

自己封じ込め原則 (S-CP)

この原則に従って、組み立て段階で、必要なすべてのコンポーネントがコンテナに含まれます。コンテナーは、システムに純粋な Linux カーネルのみがあることを前提として構築する必要があるため、必要な追加ライブラリはすべてコンテナー自体に配置する必要があります。また、対応するプログラミング言語のランタイム、アプリケーション プラットフォーム (必要な場合)、コンテナ アプリケーションの実行中に必要となるその他の依存関係なども含める必要があります。

例外は、環境ごとに異なる構成であり、Kubernetes ConfigMap などを介して実行時に提供する必要があります。

アプリケーションには、コンテナ化された Web アプリケーション内の個別の DBMS コンテナなど、いくつかのコンテナ化されたコンポーネントが含まれる場合があります。 S-CP 原則によれば、これらのコンテナは XNUMX つに結合されるべきではなく、DBMS コンテナにはデータベースの操作に必要なものがすべて含まれ、Web アプリケーション コンテナには Web の操作に必要なものがすべて含まれるように作成する必要があります。アプリケーション、同じ Web サーバー。その結果、実行時に Web アプリケーション コンテナは DBMS コンテナに依存し、必要に応じて DBMS コンテナにアクセスします。

実行時制限原則 (RCP)

S-CP 原則は、コンテナーの構築方法とイメージ バイナリに何を含めるべきかを定義します。しかし、コンテナは、ファイル サイズという XNUMX つの特性だけを備えた単なる「ブラック ボックス」ではありません。実行中、コンテナーは、使用されるメモリ量、CPU 時間、その他のシステム リソースなどの他の側面を持ちます。

ここで RCP 原則が役に立ちます。これによれば、コンテナはシステム リソースの要件を満たしてプラットフォームに転送する必要があります。各コンテナーのリソース プロファイル (必要な CPU、メモリ、ネットワーク、ディスク リソースの量) を使用して、プラットフォームはスケジューリングと自動スケーリングを最適に実行し、IT 容量を管理し、コンテナーの SLA レベルを維持できます。

コンテナのリソース要件を満たすことに加えて、アプリケーションが独自の境界を超えないことも重要です。そうしないと、リソース不足が発生したときに、プラットフォームが終了または移行する必要があるアプリケーションのリストにそのリソースを含める可能性が高くなります。

クラウドファーストについて語るとき、私たちは働き方について話しています。
上記では、クラウド環境向けの高品質のコンテナ アプリケーションを構築するための方法論的基盤を確立する多くの一般原則を定式化しました。

これらの一般原則に加えて、コンテナーを操作するための追加の高度な方法とテクニックも必要になることに注意してください。さらに、状況に応じて適用する (または適用しない) 必要がある、より具体的な短い推奨事項がいくつかあります。

• イメージのサイズを減らすようにしてください。一時ファイルを削除し、不要なパッケージをインストールしないでください。コンテナーのサイズが小さいほど、コンテナーのアセンブルとネットワーク経由のターゲット ホストへのコピーが速くなります。
• 任意のユーザー ID に注目してください。コンテナーの起動に sudo コマンドや特別なユーザー ID を使用しないでください。
• 重要なポートにマークを付ける: 実行時にポート番号を設定できますが、EXPOSE コマンドを使用して指定することをお勧めします。これにより、他の人やプログラムがイメージを使用しやすくなります。
• 永続データをボリュームに保存する: コンテナーが破棄された後も残すべきデータは、ボリュームに書き込まれる必要があります。
• 画像メタデータを書き込む: タグ、ラベル、注釈により画像が使いやすくなります - 他の開発者はあなたに感謝するでしょう。
• ホストとイメージを同期する: 一部のコンテナー化アプリケーションでは、コンテナーが時間やマシン ID などの特定の属性でホストと同期する必要があります。
• 結論として、上記の原則をより効果的に実装するのに役立つテンプレートとベスト プラクティスを共有します。
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

OpenShift Container Platform の新バージョンに関するウェビナー – 4
11月11.00日XNUMX時XNUMX分

学ぶ内容:

• 不変の Red Hat Enterprise Linux CoreOS
• OpenShift サービス メッシュ
• オペレーターフレームワーク
• Knative フレームワーク

出所： habr.com