By Marco Fioretti
マイクロサービスアーキテクチャ は、これらのプラットフォームが適切なツールで開発および管理されている場合に、大規模で拡張性の高いオンラインプラットフォームの開発と展開にかかる時間を短縮します。ここでは 開発の領域・フェーズに 焦点を当てながら、フル機能の万能フレームワークは省略して、マイクロサービスの開発に有用なアプリケーションのメジャーなカテゴリーを紹介します。これには、２つの理由があります。 1つは、良くも悪くも、この分野は非常にダイナミックであり、ツールが非常に多いため、作成したときにはリストが不完全または古くなるということです。
もう１つのより重要な理由は、開発領域に焦点をあてることで、あらゆる種類のマイクロサービスの開発前に考慮すべき主要な問題に関するアイデアを提供できるからです。
これは、マイクロサービスに関する5部構成のシリーズの最後です。このトピックを掘り下げる前に、このシリーズの以前の部分を最初に読んでおくとよいでしょう： マイクロサービス：定義と主なアプリケーション, マイクロサービスのAPI, マイクロサービスセキュリティの概要, そして マイクロサービスをどのように連携するか.
言語
マイクロサービスの開発は、Pythonのような汎用の主力製品から、次のような特殊なツールまで、多くの言語で発生する可能性があります。 Ballerina、Golang、Java EE、ASP.Net、Node.JSなどが中心的なものです。組織は、すべてのマイクロサービスプロジェクトで、これらの言語の1つ（通常はチームがすでに知っている言語）のみを常に使用したくなります。
実際には、これは原理的に間違っており（十分にテストされ、すぐに利用できるコードの使用を妨げることが多いため）、初期要件の違いから、以前のプロジェクトからのコードの再利用の利便性、または既存のサードパーティライブラリを活用まで、多くの理由で実際に達成することは困難です。したがって、ほとんどのマイクロサービスプロジェクトに有効な言語またはライブラリを選択するための唯一の提案は、コードの高い可観測性、同時実行性、高性能I / O機能、テスト自動化などの機能のサポートを探すことです。
コンテナとその管理
マイクロサービスの主な使用例は、ビジネスの需要に対応するために非常に迅速に拡張または変更する必要があるオンラインプラットフォームです。これまでのところ、このようなシナリオでマイクロサービスをデプロイするための最も一般的なツールは、コンテナーと呼ばれる仮想マシンの軽量な代替手段のバージョンです。 2022年初頭の時点で、Dockerは最も人気がありますが、 but 決して唯一の選択肢ではありません。KubernetesにDockerを非推奨とすることが が最終的に実装されたので状況は変わる可能性があります。ただし、マイクロサービスに使用するコンテナエンジンが何であれ、 ここで述べたようにセキュリティのためにロックダウンする可能性があります。
コンテンツに関係なく、コンテナの実際の展開、スケジューリング、および負荷分散には、運用を自動化し、セキュリティを最大化し、エラーの可能性を最小化するために、オンプレミス、クラウドサービス、または両方の組み合わせとして実行できる専用ツールが必要です。たとえば、コンテナ構成をコンテナイメージから切り離します。 Dockerの場合、最も一般的なソリューションはKubernetesであり、単独で、またはRedHatのOpenShiftなどのマイクロサービスに接続して保護するためのフレームワークと並べて使用します。
コミュニケーション、およびそれらのテスト
マイクロサービスが 通信のためのメッセージングとサービスディスカバリ,を必要とする場合、これらの機能を次のようなツール：Apache Kafka, RabbitMQ または Amalgam8で実装できます。.
プラットフォームのすべてのマイクロサービス間、またはマイクロサービスと( API Gatewaysを通した)外との通信は、モノリシックアーキテクチャより、テストが困難です。しかし、このテストは、次のようなソフトウェア、 Tyk, API Fortress または Postmanによって、容易となり、開発の他のフェーズと統合できる場合があります。
API管理
前回の記事で マイクロサービスにとって、APIがどれほど重要で複雑かを見ました。そのため、統合された方法で開発および管理する必要があります。これにより、APIのロードまたは作成が容易になり、マイクロサービス間だけでなく、データベースから認証までの外部サービスに接続できます。 これらのタスクを処理する方法の一例として、 DreamFactoryがあります。
アプリケーションパフォーマンスモニタリング（APM）
最後に、アプリケーションのパフォーマンスをどのように監視するかを検討します。アプリケーション監視のプログラムはソフトウェアエンジニアリングでは目新しいものではありませんが、マイクロサービスに関しては、従来のソリューションにはテストのプログラムと同じ問題があります。つまり、インターネット全体に散らばった小さなコンポーネントのクラスターを継続的に監視するのではなく、モノリシックアプリケーションを処理するように設計されています。
このようなプラットフォームの適切なAPMは、障害、ボトルネック、または非定型の動作をできるだけ早く発見するための、別のゲームのようなものです。少なくとも、プラットフォームのフロントエンドとバックエンドの両方で、より多くの場所でリアルタイムに収集すべきデータが増えています。どちらの場合も、最終的な目標は、ユーザーエクスペリエンスを改善し、パフォーマンスのボトルネックを明らかにし、障害を修復するための平均時間（MTTR）を最小限に抑えることです。より詳細には、フロントエンドAPMは、WebアプリまたはページのJavaScriptエラーから、コンテンツの読み込みやユーザーアクションへの反応に必要な平均時間まで、エンドユーザーに表示される内容に関するメトリックを収集して分析する必要があります。
一方、バックエンドAPMは、内部マイクロサービスとサーバーに焦点を当てる必要があります。たとえば、サーバーの負荷や1秒あたりのデータベース要求の数を調べたり、メモリ使用量がしきい値を超えないことを確認したりします。この分野では、Prometheus、Graphite、Kibana、Grafanaなどのオープンソースツールの組み合わせを検討する価値があります。これらのツールは、独自の完全に統合されたソリューションよりも最初は構成が難しいか、費用がかかる可能性がありますが、同時に完全にカスタマイズ可能であり、ロックインのリスクがありません。
