ソフトウェアアーキテクチャとは、ソフトウェアシステムの開発と実装における高レベルな構造のことです。ソフトウェアがますます普及し浸透するにつれて、さまざまなアーキテクチャスタイルが進化していくことになります。このような混雑した状況において、マイクロサービスアーキテクチャは多くの注目と関連性を集めています。マイクロサービス、それらがAPIを介してどのように通信するか、そしてSwaggerやSwaggerHubのようなツールがどのように役立つかについて、深く掘り下げて理解していきましょう。
マイクロサービスとは？
マイクロサービス — 別名マイクロサービスアーキテクチャ — は、アプリケーションを疎結合なサービスの集合として構築するアーキテクチャスタイルであり、各サービスはビジネス機能を実装します。マイクロサービスアーキテクチャは、大規模で複雑なアプリケーションの継続的なデリバリーとデプロイを可能にします。また、組織がその技術スタックを進化させ、時間とともにスケーラブルでより回復力のあるものになることを可能にします。 マイクロサービスアーキテクチャは、単一のアプリケーションを疎結合なサービスの集合として開発することを提唱しています。これらのユニットはまた、集中化の必要性を最小限に抑えつつ、大規模なモノリシックアプリケーションの継続的なデリバリーとデプロイを可能にします。 
(画像出典: NGINXブログ)
なぜマイクロサービスなのか？
マイクロサービスの人気の理由を理解するには、モノリシックアプリケーションを理解することが重要です。どのようなアプリケーションも、クライアント側インターフェース、データを保存および処理するためのデータベース、サーバー側ロジックで構成されます。 モノリシックアプリケーションは、単一のユニットとして構築されます。モノリシックアプリケーションでは、サーバー側ロジックはモノリスの形でまとめられ、すべてのリクエスト処理ロジックが単一のプロセスで実行されます。このシステムへのすべての更新は、サーバー側アプリケーションの新しいバージョンのデプロイを伴います。 市場には何千もの成功したモノリシックベースのアプリケーションがありますが、開発チームはこのような大規模なデプロイメント操作の重荷を感じ始めています。例えば、モノリシックアプリケーションでは、どんな小さな修正も変更サイクル全体に結び付けられ、これらのサイクルは必然的に互いに結びついています。チームはアプリケーション全体をスケーリングしなければならないため、特定の機能やモジュールのきめ細かいスケーリングも不可能です。 
(画像出典: martinfowler.com)
特にクラウド上でアプリケーションの管理、更新、デプロイの複雑さが増大するのを克服するために、マイクロサービスアーキテクチャの採用が始まりました。各マイクロサービスは特定のビジネス機能を定義し、この機能に関連する操作のみを定義するため、非常に軽量でポータブルです。マイクロサービスは、より小さなホストにデプロイして実行でき、従来のアーキテクチャのようなRAMやCPUリソースを使用する必要はありません。これらの操作は、ユースケースに応じて異なる言語で開発することもできます。例えば、メッセージボードサービスはRubyで構築でき、異なるユーザーにそれらを配信するサービスはNodeで構築できます。 上記のすべてが、マイクロサービスベースのアーキテクチャの大規模な採用に貢献しており、最も顕著な例はNetflixです。
これはSOAですか？
アプリケーション内で機能ユニットを論理的に分離する概念は新しいものではありません。最も一般的な比較は、マイクロサービスとサービス指向アーキテクチャ（SOA）の間で行われます。これについては深く掘り下げませんが、マイクロサービスとSOAにはいくつかの点で違いがあると言えば十分でしょう。SOAはインターフェースレベルで機能し、機能をサービスインターフェースとして公開することを目指します。これらのインターフェースにより、次世代のアプリケーションでデータや操作を簡単に利用できるようになります。SOAのスコープはアプリケーション間のインターフェースの標準化にあり、マイクロサービスはアプリケーションレベルのスコープを持ちます。
マイクロサービスの欠点
他のアーキテクチャスタイルと同様に、マイクロサービスにもいくつかの欠点があります。大きな問題の一つは、アプリケーション全体のビジネス機能を複数のきめ細かいユニットに分解することであり、サブビジネスユニットの境界線を引くのが難しく、厄介な場合があります。境界が適切に定義されていないと、アプリケーションのスケーリングに悪影響を及ぼす可能性があります。また、特に異なる言語で構築されている場合、異なるサービス間でコードを再利用することも困難になる可能性があります。 さまざまなサービスを実行しているホストを追跡するのは面倒であり、これらのさまざまなコンポーネントを連携させようとすることで、多くの混乱とリソースの消費につながる可能性があります。マイクロサービスアーキテクチャは、効果的に実現するために技術的なスキルも必要であり、従来のアプリケーションエンジニアリングに慣れている開発者にとっては大きな移行となります。
コンテナはどのように役立つか？
マイクロサービスアーキテクチャの採用は、その欠点のいくつかを克服する必要性を生み出しました。これがコンテナエコシステムの台頭を促しました。コンテナは、オペレーティングサービスの仮想化の一形態であり、さまざまなサービスをリソースに依存しないユニットで実行することを可能にします。Linuxコンテナはカーネルインターフェースを利用します。カーネルはオペレーティングシステムの中心的なコンピュータプログラムであり、起動時に最初にロードされるプログラムです。 
(画像出典: wikipedia)
コンテナの構成により、複数のコンテナが同じカーネルを共有しながら同時に実行でき、すべて互いに独立しています。OS仮想化は、コードの転送とデプロイメントを従来のVMよりもはるかに効率的にします。VMはハードウェアのみを仮想化します。Dockerは最も人気のあるコンテナ技術であり、非常に短期間で数千のアプリケーションで使用される標準的なLinuxカーネルベースのコンテナとなっています。 同じホストのコンテナ間の独立性により、異なるテクノロジーやフレームワークで構築されたマイクロサービスのデプロイは非常に簡単かつ直接的になります。コンテナのポータビリティと軽量性も、マイクロサービスのデプロイにとって望ましいものです。 マイクロサービス管理の問題を解決するために、さまざまなコンテナ管理システムが登場し、これらのコンテナをより適切に管理およびオーケストレーションし、クラスタサーバー全体を構成および管理できるようになりました。ここでは、いくつかの人気のあるものを比較した素晴らしい記事があります。
APIの役割
マイクロサービスは、より大きなアプリケーションを構成する独立して保守されるコンポーネントであることをご存知でしょう。また、コンテナがそれらをデプロイする優れた方法であることもご存知でしょう。マイクロサービスとコンテナは、互いに通信するためにプロセス間通信（IPC）メカニズムを使用します。これらのやり取りは次のようになります。
- クライアントリクエストが1つのサービスによって処理される1対1の通信
- クライアントリクエストが複数のサービスによって処理される1対多の通信
IPCメカニズムがリクエスト・レスポンスサイクルを含む場合、最も一般的な通信手段はRESTfulであり、ほとんどの場合HTTP/JSON APIを使用します。マイクロサービス間のIPCとして使用されるAPIは、従来の形式とは異なります。これらのAPIはよりきめ細かいものです。マイクロサービスを公開するAPIはきめ細かいデータを公開するため、クライアントは必要なデータを取得するために、サービス間で1対多の形式のやり取りに従う必要がある場合があります。 
(画像出典: IBM developerWorks)
たとえば、マイクロサービスパターンに従ってEコマースウェブサイトを構築しているとします。販売されている製品の全体像は、複数のサービスを通じて描かれる可能性があります。たとえば、タイトルや説明などの基本的な製品情報を公開するサービス、価格を公開するサービス、レビューをエクスポートするサービスなどです。製品の完全なデータを取得したいクライアントは、これらすべてのサービスを呼び出す必要があります。マルチデバイスエコシステムでは、異なるデバイスで異なるデータが必要になる場合があります。たとえば、デスクトップアプリケーションは、モバイルバージョンよりも詳細なデータを必要とする可能性があります。
マイクロサービスへのデザインファーストアプローチ
APIがさまざまなサービス間の最も一般的な通信手段となっていることはすでに説明しました。APIを介してサービスをより適切に公開するには、各サービスが正確に何をすべきかを伝える共通のインターフェースが必要です。このインターフェースは、クライアントとサービス間のSLAを定義する契約です。OpenAPI (Swagger) Specificationは、この契約を人間と機械の両方が読み取り可能な形式で定義するための標準形式として登場し、サービスが効果的に通信し、アプリケーション全体をオーケストレーションすることを容易にしています。 マイクロサービスアーキテクチャは主にエンタープライズグレードの動きであり、したがって、マイクロサービスデータを公開するAPIをファーストクラスで扱うことが重要です。多くの組織は、マイクロサービスの構築にデザインファーストアプローチを採用しています。これは、まずマイクロサービスのインターフェースを設計・定義し、この契約をレビューして安定させ、その後初めてサービスを実装するものです。デザインファーストアプローチは、実際の開発が行われる前に、サービスがクライアントの要件に準拠していることを事前に保証します。 APIに対するデザインファースト（またはAPIファースト）アプローチを採用する際のいくつかの重要な考慮事項を次に示します。
市場投入までの時間
マイクロサービスはその性質上、内部的なものであり、最小限の計算能力と使用時間を持つことを意図しています。これはそれらを公開するAPIにも当てはまります。そのため、迅速なAPIデリバリー率を達成するために、これらのAPIの設計、ドキュメント化、および開発を自動化することが重要です。Swaggerインターフェースは、クライアントとサービス間の共通のSLAを定義するだけでなく、サーバーとクライアントのテンプレート、およびテストケースの生成を可能にし、開発とテストのプロセスをはるかに容易にします。 インテリジェントな設計のためのスマートAPIエディタと、API設計の迅速な提供を可能にするドメインを提供するSwaggerHubのようなプロフェッショナルツールは、APIの市場投入までの時間を短縮するのに役立ちます。
柔軟なオーケストレーション
マイクロサービスを公開するAPIがきめ細やかで細分化されていると述べました。これは、特定のエンティティのデータが必要なクライアントアプリは、必然的に複数のAPIを呼び出す必要があることを意味します。マイクロサービスベースのアプリケーションのデータ交換を処理する複雑さは大きな問題です。 複数のサービスリクエストを処理する解決策は、単一のエントリポイントを通じてリクエストを処理できるAPIゲートウェイを実装することです。ゲートウェイの基本API契約上のすべてのAPIがOpenAPI/Swagger Specificationで定義されているため、APIゲートウェイを介して設計フェーズからデプロイフェーズへ効率的に移行することは非常に簡単になります。SwaggerHubは、AWS、Azure、IBM API ConnectなどのAPIゲートウェイと直接統合されており、これらのリクエストを効率的にオーケストレーションしたい組織向けに設計されています。
責任ある設計
複数のチームが異なるサービスを構築することは厄介な場合があります。人的資源の管理が難しいだけでなく、これらのチームがサービスのインターフェースを開発し始めると、さらに複雑になる可能性があります。複数のチームがRESTfulインターフェースを定義・構築する際に、URL構造、応答ヘッダー、リクエスト・レスポンスサイクルオブジェクトにおける設計パターンの相違は非常によくあることです。 インターフェースはクライアントとサービスがどのように相互作用するかを定義するため、設計に違いがあると、サービスの開発フェーズで混乱とオーバーヘッドが生じます。これを修正しようとすると、時間、費用、人的資本という形でリソースが費やされるだけです。 これは、SwaggerHubの2つの主要な設計機能であるドメインとスタイルバリデーターを使用することで克服できます。スタイルバリデーターは、RESTfulインターフェースが組織の要件に基づいて標準の設計図に準拠していることを保証します。これは、すべてのインターフェースがキャメルケース演算子を持ち、応答パケットに例が定義されているか、モデルがローカルで定義されていることを意味する場合があります。 ドメインでは、モデルやリクエスト・レスポンスオブジェクトなど、共通の再利用可能な構文を保存でき、マイクロサービスビジネス機能を公開する複数のAPI間で迅速に参照できます。これにより、APIスタイルに対してよりきめ細かいアプローチが可能になり、サービスを公開するすべてのRESTful設計に対して1つの中央制御センターを持つことができます。ドメインとスタイルバリデーターはSwaggerHub独自の機能であり、サービスIPCを構築する際の設計の一貫性と迅速な市場投入を保証します。
ウェビナー：エンタープライズをAPIプラットフォームに移行するための教訓
あなたのデジタル変革の取り組みは、ビジネスを正しい方向に導いていますか？4月10日、私たちは無料ウェビナー「企業をAPIプラットフォームへ転換する教訓」を開催します。このセッションでは、ホスピタリティ、融資、フィンテックのさまざまな組織と協力して、APIプラットフォームの開発と展開から学んだ教訓に焦点を当てます。これらの企業は、全体的なプラットフォーム戦略の一環として、APIファースト設計、フェデレーションガバナンス、およびAPI管理レイヤーを実装しました。何がうまくいき、何がうまくいかなかったのか、そして変革イニシアチブを円滑に進めるためのヒントを探ります。議論されるトピック
- 内部再利用と活発なパートナープログラムを促進する効果的なAPIプログラムの開発
- 集中型ガバナンスと連合型ガバナンスの探索を含む、APIガバナンスを実装するための手法
- マイクロサービスとモジュラーソフトウェア設計が今日の企業の文化をどのように変えているか
- 優れたポータルと開発者サポートプロセスを開発することでAPIのオンボーディングと採用を増やす
- 企業に対するAPI中心のアプローチで変革の取り組みを加速するためのヒント
今すぐ登録 