How to develop a standard cloud-native application

クラウドネイティブを数字で理解する

IDC の予測によると、2024 年までに、マイクロサービス、コンテナ、動的オーケストレーション、DevOps などの技術の採用により、新規アプリケーションにおける本番環境レベルのクラウドネイティブ アプリケーションの割合は、2020 年の 10% から 60% に増加し、そのうちマイクロサービスのワークロードは企業内で 80% を超えるとされています。以上の 4 つは、クラウドネイティブ時代を代表する 4 つのコアテクノロジーです。中でも、開発者の皆さんはマイクロサービスに特に注目していることでしょう。近年の傾向として、Java 分野でのマイクロサービス フレームワークはますます成熟し、クラウドネイティブとの統合も緊密になっています。EDAS のデータを見ると、Spring Cloud + Kubernetes がマイクロサービス アーキテクチャの主流の組み合わせとして定着しています。しかし、もう 1 つ気になるデータがあります。現在、クラウドネイティブ シナリオでのマイクロサービス本番運用経験を持つ開発者は 8% 未満です。なぜこうなったのでしょうか。主な理由は 2 つあると考えます。

まず、マイクロサービス自体の学習曲線が急峻であり、フレームワークを習得して本番環境での実践を行えるようになるまでには時間がかかります。それに加えて、クラウドネイティブの多くの複雑な概念や、複雑な環境構築の技術的課題に直面します。これら 2 つの要因が重なり、未知の世界への不安を感じる方が多く、戦略的な意思決定が十分でないチームでは、最終的に導入効果があまり芳しくない結果になっています。

これを踏まえて、当チームのプロダクトと関連コースを活用していただくことをお勧めします。クラウドネイティブ チームでは Alibaba Cloud University で学べる多数の関連コースを用意しており、多くのプロダクトでも便利なツールを提供しています。また、研究開発チームにおけるマイクロサービス実装をはじめとする、さまざまな分野でのデジタルトランスフォーメーションの豊富な経験があります。興味のある方はお気軽にお問い合わせください。選択的に深いコミュニケーションを行うことができます。

次に、開発者の方には、クラウドネイティブ アプリケーションと通常の開発アプリケーションに違いはないという誤解が従来からあります。開発者にとっては、これまでと同じようにコードを書き、デプロイして、トラブルシューティングを行うだけだからです。しかし、実際には大きく異なります。何が違うのでしょうか。Heroku は 12 の要素をまとめてくれました。これは業界で「12 Factor App」と呼ばれています。この 12 の要素を満たすアプリケーションのみが、クラウドネイティブ アプリケーションと呼べるのです。

Twelve Factor App

ここに 12 項目を列挙しました。オレンジ色の部分は今日のコンテンツに関連する箇所です。各項目について簡単に説明します。

第 1 条：Codebase (コードベース)。1 つのコードを複数箇所にデプロイするという原則です。逆に言えば、複数のデプロイ先はすべて同じコードでなければならず、必ず 1 つのコードである必要があります。これが守られていないのはどんな場合でしょうか。たとえば、本番環境で直接変更を加えたが同期し忘れた場合などが該当します。つまり、これは研究開発プロセスを規律付け、各環境間でのコードの一貫性を保つためのものです。

第 2 条：依存関係の明示と宣言。これは理解しやすいでしょう。Java で開発している方は ant、maven、gradle などのツールを使って依存関係を明示的に宣言しているはずです。ただし、2 つのポイントを見落としがちです。1 つ目はスナップショット バージョンへの依存で、効果的な追跡ができていない結果、本番環境での障害につながることです。2 つ目は暗黙的な依存関係、つまりコードの実行環境がシステム ソフトウェアや実行エンジンに依存している部分も、アプリケーションの一部として考慮すべきということです。

第 3 条：Config (設定)。一般的な理解ではコードと設定の分離です。厳密には、動作環境全体 (イメージ) を設定から切り離すことを意味します。どういうことかというと、ここでの核心は、アプリケーションの実行および起動プロセスにおいて、依存する設定が通常の運用保守の手段で柔軟に置き換えられるかどうかです。これらの運用保守の手段には、環境変数の変更、起動パラメータの変更、分散設定を介したサービスの設定変更などが含まれます。

第 4 条：Backing Services (バッキング サービス)。すべてのバックエンド サービス、すべてのネットワーク呼び出しを含むすべてのバックエンド サービスは、同じ視点から扱う必要があります。付加リソースとして扱うことには 2 つの意味があります。1 つ目は、Java の URI インターフェイスなど、リソースへのアクセス方法とインターフェイスです。もう 1 つの理解は、リソースである以上、その可用性も考慮する必要があるということです。すべてのバックエンド サービスがリソースである以上、リソースの可用性も同等に扱うべきです。

第 5 条：Build、Release、Run の厳格な分離。これら 3 つの領域で注目すべき能力が異なるため、厳密に分離する必要があります。まず、Build は実際のビルド結果に重点を置きます。Release は戦略に焦点を当てるべきです。Run フェーズでは、トラフィック管理に最も注意を払い、トラフィックを可能な限り無損失にする必要があります。

第 6 条：Stateless (ステートレス)。純粋なプロセス次元のステートレス性は、主にプロセス起動時のデータへの依存に関するものです。ステートレス性の目的は、高速なスケーリング、さらには自動スケーリングをより良く実現することです。ステートレス + 介入なしの起動が、弾力性を実現するための重要なステップです。

第 7 条：Port Binding (ポートバインディング)。すべての公開サービスはポート経由で公開されるべきです。これに反して、一部のアプリケーションは UNIX ソケットや IPC を通じてサービスを提供し、大規模なサービス運用保守シナリオでの複雑性を大幅に増大させます。

第 8 条：Processes (プロセス)。ここでの考え方は、サービス容量を柔軟に拡張する必要がある場合、スケールアップではなくスケールアウトをプロセスレベルで推奨するというものです。スケールアウトにより、アプリケーションはさまざまな仕様のシステム リソースを最大限に活用できます。一方、スケールアップは追加のシステム オーバーヘッドをもたらし、JVM のような仕組みではより複雑な GC 戦略を必要とすることが多いです。

第 9 条：Disposability (ディスポーザビリティ)。クイックスタートのシナリオをより長期的な視点で捉える必要があります。第 5 条の Run フェーズに戻ると、Run フェーズとは新しい環境が開始準備を整えてからプロセスが実際にサービスを開始するまでを指します。つまり、環境準備、パッケージの取得、プロセス起動のすべての後続プロセスを含みます。一方、グレースフル ターミネーションでは、メッセージ、スケジューリング タスク、スレッド プールなどのバックグラウンド タスクの処理が見落とされがちです。

第 10 条：Dev/prod parity (開発/本番環境の同等性)。理解は容易ですが実装は困難です。これを実現する前提条件は、環境に対するすべての人手による操作を排除することです。クラウドネイティブには「イミュータブル インフラストラクチャ」という概念があり、これに対応しています。ただし、イミュータブル インフラストラクチャとは、実行時にコード内で厳密に遵守すべき設定を指し、変更が必要な場合は再度宣言する必要があります。

第 11 条：Logging Event (ログ イベント)。ログをイベント ストリームとして処理することを推奨します。具体的には、すべてのログを設定ファイルではなく標準出力に出力することを推奨します。同時に、専用の集中型ログ サービスを使用してログ内容を収集し、集約、クリーニング、クエリを一元的に行います。これは単なる運用保守の標準化にとどまりません。さらに、ローカル ディスクへの依存をデカップリングできます。クラウドネイティブ シナリオのアプリケーションでは、ディスク データがいつでも消失する可能性に備える必要があります。

第 12 条：Background management tasks (バックグラウンド管理タスク)。ログのクリア、キャッシュ クリア、データの修正など、メンテナンス性のタスクを指します。これらはビジネスの一部として扱い、プロダクト システム全体から切り離さないようにすべきです。前述の 11 項目と同じ原則に従う必要があります。たとえば、単一コードベース、明示的な依存関係の宣言、コードと設定のデカップリング、ステートレス性などです。

従来のオープンソース ソフトウェア構築

まず、マイクロサービス環境を準備する必要があります。最も基本的なものは、マイクロサービス シナリオでのサービス登録とサービス検出のためのコンポーネント (Nacos など) です。もちろん、ビジネスが複雑化するにつれて、APM コンポーネントやログ サービス コンポーネントなど、より多くのコンポーネントが必要になります。

次に、ローカルで IDE を使用してコード プロジェクトを構築し、開発を開始します。Java では、mvn を使用して依存パッケージ管理を行います。

3 番目に、コードを Git リポジトリにコミットします。環境変更に関するすべての操作は、Build/Release/Run のプロセスに従って厳密に分離する必要があります。現在、Jenkins を使えばこれを効果的に実現できます。Jenkins でパイプラインを作成すると、プログラムのビルド、イメージのビルド、イメージのアップロードなど、複数のタスクを含む一連の処理が行われます。最後に、Kubernetes に対して対応するワークロード変更が開始されます。

EDAS Core がオープンソースの 4 ステップを 1 ステップに

EDAS チームはより便利な方法を提供します。それは Alibaba Cloud のプロダクトである EDAS Core です。EDAS にはアプリケーション ライフサイクル管理やマイクロサービスのサービスガバナンス機能が含まれ、Webshell も標準搭載されています。最小構成でのインストールは 4C8G のみで済み、軽量でシンプルです。ラップトップでも起動でき、標準的な Kubernetes クラスターにもインストールできます。開発およびテスト用に無料で利用できます。前述の 4 ステップを 1 ステップに集約できます。

インストール手順

第 1 ステップ：EDAS Core のインストール パッケージをダウンロードして展開します。

第 2 ステップ：クラスターに関連する kubeconfig ファイルを確認し、対応する場所に配置します。

第 3 ステップ：インストール ディレクトリに入り、インストール スクリプトを実行します。全体のプロセスは約 7〜8 分かかります。

EDAS Core の使用には、複雑な Dockerfile やイメージの準備は不要です。対応する環境を順次選択し、通常のパッケージをアップロードして、対応するルール パラメータを設定するだけで済みます。さらに、マイクロサービスに関連する Nacos コンポーネントの構築やアドレス パラメータの設定は、デフォルトで自動管理されます。

同時に、EDAS を使用して Jenkins と連携するための公式 Jenkins プラグインも提供されています。プラグインに EDAS アプリケーション ID とデプロイメントパッケージのアドレスを入力するだけで、パイプラインとの連携を完了できます。

マイクロサービス開発における課題

環境構築は最初のステップに過ぎません。マイクロサービスの開発において、課題の 1 つは、独自開発したアプリケーションを既存の大規模なエコシステム クラスターにどのように統合するかということです。また、2 つのアプリケーションが新しい機能を同時にリリースする必要がある場合、2 人の開発者が他の人に影響を与えずに、特定のトラフィック ルールに従って正確に共同デバッグを行うにはどうすればよいかという課題もあります。以下に示します。

エンドクラウド相互接続

上記 2 つの課題を解決するため、Alibaba Cloud Toolkit の「エンドクラウド相互接続」機能をお勧めします。このソリューションでは、SSH ポートに接続可能な踏み台サーバーを用意するだけで、上記 2 つの課題を完全に解決できます。

同時に、正確な共同デバッグのシナリオでは、EDAS でスイムレーン グループを作成し、エントリー アプリケーションを指定して、クラウド側でトラフィック ルールを設定します。同時に、2 人の開発者にこのスイムレーン グループに参加してもらいます。すると、ルールに合致するすべてのトラフィックが互いのノードに正確にルーティングされます。

それだけではありません。Cloud Toolkit には IDE から環境へ直接ワンクリックでデプロイする機能や、ワンクリックで Pod にアクセスできる Webshell 機能も備わっており、トラブルシューティングや診断を容易にします。この機能は EDAS 商用版でも近日中に提供予定です。

すべてのアプリケーションの開発が完了したら、新しいテスト環境、負荷テスト環境、プレリリース環境、本番環境など、多くの新しい環境を準備する必要があります。アプリケーション数が増えるたびに、運用担当者は環境準備に苦慮することになります。このシナリオに対応するため、EDAS Core はすべてのアプリケーションをワンクリックでクラウド上に構築する機能を開発しました。

最後のお楽しみ：Chengdu 環境で無料版をリリース

クラウド移行後に商用版のコストを心配する方のために、EDAS は 8 月末に Chengdu で新しいアプリケーション フォームをリリースしました。このフォームでは、EDAS がコントロールプレーン、マイクロサービス ガバナンス、APM モニタリングの 3 つの機能を分割し、必要に応じて柔軟にカスタマイズできます。ぜひお試しください。フィードバックをお待ちしています。