2024 年にクラウドネイティブアーキテクチャに必要なテクノロジースタックは何ですか?

背景

時は経つのは早いもので、もう2024年です。2015年に就職したばかりの頃は、SSM/H（Spring/Struts2/Mybatis/Hibernate）フレームワークをマスターすれば、ほとんどの面接に合格できたことを今でも覚えています。

おそらく、新しい CS 専攻の学生は SSM について聞いたことがないと思います。

たまたま、私は働き始めた頃のモバイルインターネットブームから、eコマース→シェアリングエコノミー→toBの普及→今に至るまで、あらゆることを経験してきました。テクノロジースタックも、当初の単一アプリケーション + 物理マシンから現在の Kubernetes クラウドネイティブアーキテクチャへと進化しました。

もちろん、SOA サービス指向 -> マイクロサービス -> クラウドネイティブ -> サービスメッシュ -> サーバーレスなど、その過程でいくつかの主要な段階を経てきました。

私の最近の仕事は主にインフラに重点を置いたもので、インフラに関しては比較的包括的な理解を持っていると思います。そこでこの記事では、2024 年にどのようなクラウドネイティブテクノロジースタックを使用すべきかを私の観点から共有します。多くの技術的要素が関係するため、あまり詳細には触れません。

ただし、ここで紹介するテクノロジースタックはすべて私が実際に使用したものであり、実際の経験に焦点を当てて、その長所と短所について述べることを保証できます。

オペレーティング·システム

1 つ目はオペレーティングシステムです。これは、従来のオペレーティングシステム (Linux/Windows Server/MacOS) とは異なります。主に選択の余地があまりないクラウドネイティブなオペレーティングシステム、つまりKubernetesを指します。

しかし、Kubernetes をどのように保守するかは難しい問題です。昨年後半にDidiで事故が起き、Kubernetesのバージョンアップによる問題ではないかとネット上で噂されたことを今でも覚えています。

私たちの経験に基づいて、小規模なチームにはクラウドベンダーでコンテンツを直接ホストすることをお勧めします。 Kubernetes のメンテナンスは非常に複雑な作業です。小規模なチームには通常、複数の責任があり、自己メンテナンスによって問題が発生する可能性が高くなります。

もちろん、大規模なチームの場合は、リスクをカバーできる限り、問題が発生しても迅速に対応できる専任のメンテナンス担当者を配置することが最善です。

私たちは小規模なチームなので、コストと安定性を考慮して、クラウドベンダーの Kubernetes 機能のみを使用しています。残りの制御可能なコンポーネントは私たち自身で保守します (これについては後で詳しく説明します)。

マルチクラウドの利点とメリット

クラウドベンダーのコンテナサービスを利用しているため、昨年の Alibaba Cloud の障害など、クラウドベンダーの障害によって発生する可能性のある問題も考慮する必要があります。

そのため、中規模企業や大規模企業の中には、マルチクラウドソリューションを選択し、複数のクラウドサービスプロバイダーに同じコードを展開して、いずれかのプロバイダーで問題が発生した場合にすばやく切り替えられるようにしているところもあります。

しかし、具体的な実装プロセスには、データの一貫性をどのように確保するかという最も困難かつ最も重要な問題など、多くの課題があります。

もちろん、分散展開をサポートし、それ自体がデータ同期をサポートするデータベースやミドルウェアを使用することもできます。たとえば、メッセージキュー内の Pulsar はグループのレベル全体に展開され、メッセージを同期できます。

同時に、マルチクラウド展開のコストも増加するため、「コスト削減と効率化」の観点から慎重に検討する必要があります。そこで、これに対する妥協案があります:

当社の技術アーキテクチャは、他のクラウドサービスに迅速に移行できる必要があります。たとえば、MySQL の binlog や一部のミドルウェアメタデータなどのリソースを定期的にバックアップし、このメタデータに基づいてビジネスを迅速に復元できる社内ツールがいくつかあります。

一般的に、クラウドサービスを切り替える必要があるのは常に極端な状況であるため、操作中にある程度のデータ損失を許容することは許容されます。最も重要なデータが失われず、ビジネスに影響が及ばないようにすることだけが必要です。

言うのは簡単ですが、シミュレーション演習に時間を費やす必要もあります。実施されるかどうかは、クラウドサービスの停止によって生じる損失と訓練のコストを企業が受け入れられるかどうかによって決まります。

メタデータを復元することはできますが、ランタイムデータの一部は失われます。

デブオプス

クラウドネイティブオペレーティングシステムとして Kubernetes を選択したため、継続的インテグレーションとリリースも Kubernetes に基づく必要があります。

上の図は、gitlab+ArgoCD で Git を使用するフローチャートです。私たちはソースコードの管理に GitLab を使用し、継続的インテグレーションに Pipline を使用し、最後に Kubernetes プロセスを開くために Argo を使用します。

これはよく GitOps と呼ばれます。

同時に、履歴バージョンのロールバックや容量の拡張と縮小はすべて Kubernetes によって提供され、DevOps プラットフォームでは Kubernetes API を呼び出すだけで済みます。

もちろん、FinOps は今人気があります。私の理解では、主にクラウドコストの管理と最適化が関係していると思います。私の仕事は、ビジネスに影響を与えることなく、未使用のリソースをリサイクルし、構成を適切に削減することです。

サービスメッシュ

次は、Service Mesh の最も重要な部分だと考えています。これについては多くの背景話があります。本質的には、これはすべて RPC (リモートプロセスコール) によって引き起こされ、配布によってもたらされると思います。

最初の単一マシンのローカル関数呼び出しから始めます。

 local+------>remote +------> micro-service+----->service-mesh + | + vvv +---+----+ +-----+------+ +----+----+ | motan | | SpringCloud| | Istio | | dubbo | | Dubbo3.0 | | Linkerd | | gRPC | | SOFA | | | +--------+ +------------+ +---------+

主に、RPC フレームワーク、マイクロサービス、そして現在のサービスメッシュという、上記の 3 つの重要な段階を経てきました。

RPC フレームワークは主に、分散通信を簡素化し、ビジネスそのものにのみ集中するのに役立ちます。
マイクロサービスフレームワークの出現により、電流制限、ルーティング、劣化、その他の機能など、大量のサービスをより適切に管理できるようになり、分散アプリケーションの堅牢性が向上します。
今日のサービスメッシュにより、アプリケーションはよりクラウドネイティブになり、マイクロサービスフレームワークを維持する必要なくビジネス開発に集中できるようになります。これらすべての基本機能を基本レイヤーに導入することで、マイクロサービスフレームワークに劣らない機能も実現します。

ただし、Istio の使用には高い技術的ハードルもあります。以下の条件を満たす場合は、Istio を使用することをお勧めします。

アプリケーションはKubernetesプラットフォームに接続されました
gRPC通信フレームワークはアプリケーション間で使用されます
APIゲートウェイもIstioゲートウェイに移行
会社には、Istio のメンテナンスに専念する人が少なくとも 1 人必要です (ここでのメンテナンスとは、必ずしもコードを理解することではなく、Istio 自体の機能とドキュメントに精通している必要があります)。

さらに、SpringCloud、Dubbo、kratos、go-zeroなどのマイクロサービスフレームワークを使用することも可能です。

可観測性

今日では、可観測性システムはますます重要になっています。個人的には、技術チームを評価するための重要な指標は、そのチームの可観測性システムがどれだけうまく機能しているかであると考えています。

優れた可観測性システムは、システムの動作状態を明確に把握し、問題を効率的にトラブルシューティングし、タイムリーな障害アラームを提供できます。

上記の基準を達成するには、観測可能なシステムの 3 つのコア指標が必要です。

メトリクスを使用すると、Grafana でさまざまな直感的なパネルを描画できるため、システムの動作状態をより包括的に把握できます。

トレースを使用すると、システムコールの全体像を把握できます。トレースにより、リクエストがどのシステムを通過したか、どこで問題が発生したかを知ることができます。
ログは比較的理解しやすいです。これらは、アプリケーションで印刷されるログの一部です。これまでの開発モードとの唯一の違いは、クラウドネイティブシステムでは、標準出力と標準エラーストリームに直接出力することが推奨されていることです。一部のサードパーティの収集コンポーネントを使用すると、より便利にデータを収集できます。

私たち自身の観測システムは反復を経てきました。以前のテクノロジースタックは次のとおりです。

Metrics は VictoriaMetrics を使用します。これは、Prometheus と完全に互換性がある時系列データベースですが、Prometheus よりもリソース効率に優れています。
Trace は、Java トレース分野でも人気のある技術ソリューションである SkyWalking を選択しました。
ログ: Filebeat を使用してログを収集し、ElasticSearch に出力します。これも古典的な解決策です。

昨年末、私たちは比較的大きな変革を行い、主に SkyWalking を、よりオープンなコミュニティであり、徐々にクラウドネイティブの可観測性の標準になりつつある OpenTelemetry に置き換えました。

これを使用することで柔軟性が高まり、特定のテクノロジースタックに縛られる必要がなくなります。現在、ログは切り替えられておらず、コミュニティはまだベータテスト中です。成熟した後は、OpenTelemetry を直接使用してログを収集することもできます。

メッセージキュー

ここでメッセージキューを特に取り上げる理由は、現在主に社内のメッセージキューを管理しているからです。同時に、ビジネス規模が大きくなるにつれて、メッセージキューが非常に重要になります。通常、さまざまなビジネスラインを接続するためのブリッジとして、またはデータベースを MySQL と同期するためのチャネルとして機能します。つまり、用途は多岐にわたります。

ここでは、クラウドネイティブにより適したメッセージキューである Pulsar を引き続き推奨します。ストレージとコンピューティングを分離したアーキテクチャのため、Kubernetesの特性と合わせて迅速な容量拡張・削減を実現でき、Kafkaよりもメンテナンスが容易です。同時に、コミュニティも非常に活発で、バグ修正や新機能のサポートにも比較的積極的に取り組んでいます。

Pulsar は幅広いクライアントを公式にサポートしています:

言語	ドキュメント	リリースノート	コードリポジトリ
ジャワ	ユーザードキュメント APIドキュメント	スタンドアロン	バンドル
C++	ユーザードキュメント APIドキュメント	スタンドアロン	スタンドアロン
パイソン	ユーザードキュメント APIドキュメント	スタンドアロン	スタンドアロン
Goクライアント	ユーザードキュメント APIドキュメント	スタンドアロン	スタンドアロン
Node.js	ユーザードキュメント APIドキュメント	スタンドアロン	スタンドアロン
C#/ドットパルサー	ユーザードキュメント	スタンドアロン	スタンドアロン

もう 1 つの質問は、Pulsar クラスターをどのように展開するか、プライベートで展開するか、クラウドサービスを購入するか (現在、Pulsar の商用会社である streamnative と国内の Tencent Cloud が同様のサービスを提供しています) です。

価格については以前相談させていただいたのですが、比較的自社で導入する方がコストパフォーマンスは高いです。前述のとおり、当社ではクラウドベンダーの Kubernetes サービスのみを使用し、これに基づいて独自のサービスを展開しています。

活発な Pulsar コミュニティのおかげで、メンテナンスに問題があっても、タイムリーなフィードバックを得ることができます。同時に、遭遇した落とし穴を通じてコミュニティに貢献することもできます。

ビジネスフレームワーク

最後のステップは、ビジネスフレームワークを選択することです。この決定の前提は、まず主要なビジネス言語としてどの言語を選択するかを決定する必要があるということです。

これはKubernetesにとって重要ではありませんが、私がよりよく知っているJavaとGolangで紹介します。

ジャワ

Java には多くの技術的なオプションがあります。 Kubernetesのみを使用し、サービスグリッドを使用しない場合は、 springboot http インターフェイスの開発は、単一のアプリケーションを開発するのと同じくらい簡単です。

ただし、これには一部のサービスガバナンス機能が欠けており、小規模および中規模のチームに適しています。

チームの人数が多く、サービスメッシュを使用していない場合は、前回の記事で紹介したマイクロサービスフレームワーク (Dubbo、SpringCloud など) を使用することをお勧めします。

専用のクラウドネイティブチームがある場合は、サービスメッシュソリューションを使用することをお勧めします。これにより、上記の 2 つのソリューションの利点を組み合わせることができます。

コードは簡潔で、http を gRPC に置き換えるだけです。
同時に、Istio を利用すると、マイクロサービスフレームワークの機能も利用できるようになります。

Go言語

Golang は実際には Java に似ています。小規模および中規模のチームの場合、開発には Gin などの http フレームワークを使用できます。

中規模および大規模のチームには、kratos や go-zero など、Dubbo や SpringCloud に匹敵する Golang エコシステムのフレームワークもあります。

Golang のシンプルさのおかげで、ビジネス開発には Java を使用するよりもはるかにシンプルで「頭を使わない」方法だと感じています。

同様に、将来的にはサービスメッシュに切り替えることもできます。 gRPC と Golang を直接使用することも非常に適応性があります。この時点で、チームは比較的成熟しており、gRPC に基づく開発スキャフォールディングを完全に作成したり、Kratos または go-zero を使用してサービス呼び出しモジュールを削除したりできるはずです。

要約する

上記は、現在普及している技術的ソリューションについての私の個人的な理解であり、さまざまなチーム規模に応じた推奨事項も示しています。確かに完璧な技術的解決策は存在せず、最も適切な解決策があるだけです。トレンドに従って、自分では制御できないテクノロジースタックを選択しないでください。そうしないと、最終的に苦しむのは自分自身になる可能性があります。

参考リンク: