マイクロサービスとは APIとの関係と課題

マイクロサービスとは

APIとの関係と課題

マイクロサービスとは、「単一のアプリケーションを小さなサービスの集合体として開発する開発技法の1つ」です。マイクロサービスを定義する方法は色々ありますが、このように述べるMartin Fowler氏によるマイクロサービスの定義が一般的です。これらのマイクロサービスはビジネス機能を中心として構築され、個別に展開可能です。これらのサービスは必要最小限の集中管理が行われ、異なるプログラミング言語で記述できます。

マイクロサービスとAPIの関係（違い）

マイクロサービスとAPIは大きな注目を集めています。しかし、マイクロサービスとAPIの関係と、この2つが異なるものであるという点について、若干混乱があるようです。マイクロサービスとは、アプリケーションの各要素を自己完結型の小さなサービス（これらがAPIです）に分割するアーキテクチャーという意味です。APIとはあくまでインターフェイスという意味であり、あるコメンテーターはAPIを「資産のセルフサービスによる使用、シンプルさ、セキュリティ、分析、そしてデリバリーのスピードに重点を置いている」と評しています。

かつてIT業界では、モノリシックまたは サービス指向アーキテクチャー（SOA）ベースのソリューションが標準でした。しかし、ますます複雑化する今日のインフラストラクチャーを考えれば、SOAでは絶えずダイナミックに拡大し続ける要求を満足することはできません。マイクロサービスは、高いレベルの俊敏性と迅速なデリバリー、そしてスケーリングを実現できるように設計されています。

マイクロサービスに関する誤解

マイクロサービスアーキテクチャーの詳細に入る前に、マイクロサービスに関するいくつかの誤解を解いておきたいと思います。まず、名前に「マイクロ」と付いていることから、このサービスはごく小さなもので、複雑な機能を持たせるべきではないと考える人がいるかもしれません。しかし、そうではありません。マイクロサービスが小さなコンポーネントであるというのは事実です。しかしｍｇｆasdghjjhgfdytr@[、大規模で複雑なものから非常に小さいものまで、さまざまなビジネス機能を担うことができます。ログインシステムや決済エンジンなどがその例です。

また、マイクロサービスは新しい種類のプロトコルだと思い込んでいる人も多いです。しかし、マイクロサービスは新しいものではありませんし、プロトコルでもありません。上述のように、マイクロサービスアーキテクチャーでは、RESTやSOAPサービスのような既存のAPI、AMQP、JMSを利用します。

マイクロサービス入門

マイクロサービスの基本的なコンセプトは、「1つのことしかできないが、それを非常にうまくこなす小さなアプリケーション」です。マイクロサービスには、以下の特徴があります。

• 交換が容易
• 独立して開発される
• 独立して展開可能

マイクロサービスは独立して開発され、展開可能ですが、それ単体で完結するわけではありません。通常、1つのアーキテクチャーやソリューションには多くのマイクロサービスが含まれており、それらは互いに通信する必要があります。1つのマイクロサービスは大きなエコシステムの一部であり、他のマイクロサービスと一緒に動作することによって、通常であれば1つの大きなスタンドアロンアプリケーションで行われる処理を実行します。

マイクロサービスはどのようにプロセス上の課題を克服するか

SOAに代表される、従来の手法にはいくつかの課題があったことから、マイクロサービスアーキテクチャーへの依存度が高まってきました。モノリシックなアプリケーションを、並行性やパーティショニングによって独立した多くの小さなアプリケーションに分割した場合、アプリケーションに必要な効率が維持できなくなります。アプリケーションでタスクを処理する必要がある場合、私たちは通常、処理効率が高いほど良いと考えます。時間が経つにつれて、ビジネス機能の拡大にあわせてアプリケーションにも機能が追加されて巨大化し、トラフィックも増大して、スピードと効率の低下につながります。そして、いずれスケールアップが必要となるタイミングが来ますが、マイクロサービス以前の時代には、タスクを分割する主な方法は並行性とパーティショニングでした。

しかし、1つの巨大なアプリケーションをすべてのサーバーに展開して、あらゆる種類のタスクを処理する必要がある場合、並行性とパーティショニングでは結局のところ対応が困難です。複雑化したアプリケーションでは、垂直スケーリングがしばしば解決策となりました。これは、ハードウェア側を増強してサーバーを追加するか（アプリケーションのコピーを他のサーバーに展開します）、アプリケーションを垂直スケーリングするかのいずれかで実現されました。この手法によって効率は向上しますが、アプリケーションはさらに複雑化します。

マイクロサービスエコシステムのベストプラクティス（フレームワーク）

マイクロサービスは大規模なインフラストラクチャーを必要とするのに加えて、ゼロから構築される必要があります。マイクロサービスは孤立したものではなく、マイクロサービスエコシステムという独自の環境で実行され、相互にやり取りするように構築されています。

マイクロサービスの構築においては、持続可能性を念頭に置く必要があります。環境を安定させる方法や、スケールアップの方法、信頼性や耐障害性を確保する方法を理解する能力が求められます。マイクロサービスエコシステムのベストプラクティス（フレームワークワーク）は、4つのレイヤーに分けることができます。

• ハードウェア：マイクロサービスにおけるこのレイヤーには、物理的なホストサーバーやデータベース、オペレーティングシステムが含まれます。標準のオペレーティングシステムを1つに統一するのが理想です。Linux、Solaris、Windowsのいずれであっても、AnsibleやChef、Puppetなどの構成管理ツールを使用して構成を行う必要があるだけでなく、すべてのアプリケーションのインストールと必要な設定にも、それらのツールを使用する必要があります。そうしないと、スケーリングの際にすべての構成をやり直す必要が生じるというスケーラビリティの問題が発生します。また、問題を早急に解決するために、ホストレベルでのモニタリングも必要となります。
• 通信：マイクロサービスインフラストラクチャーにおけるこのレイヤーは、他のすべてのレイヤーに影響を与えます。適切な通信がなければ、アーキテクチャーの他のどの部分も動作することができません。データに関しては、マイクロサービスではHTTP+RAF、またはTIFF通信チャネルを使用できます。メッセージングについては、マイクロサービスはHTTPまたは選択したプロトコルを使用してネットワーク経由でメッセージを送信します。また、マイクロサービスインフラストラクチャー間の動的な通信を促進するために、通信レイヤーに検出とレジストリ、ロードバランシングを含めることも非常に重要です。
• 開発：このレイヤーではアプリケーションの開発が行われるため、新しいデータベースやテーブル、メッセージブローカー、スキーマ、ポートの作成を可能にする、すべてのセルフサービス開発ツールが収容されている必要があります。ロギングおよびモニタリングツールの組み込みは、開発レイヤーにおける重要なステップです。すべてが正常にビルドされ、テストされていれば、展開は自動的に行われます。
• マイクロサービス：最後のレイヤーは、マイクロサービスが存在し、実行される場所という最もシンプルなものです。ここには設定ファイルが置かれるとともに、変更が必要な場合には他のレイヤーのセルフサービスツールも置かれます

ソフトウェアやアプリケーションの開発において、マイクロサービスアーキテクチャーの人気はますます高まっています。マイクロサービスが採用しているモジュール式のスタイルによって、継続的デリバリーの実践が可能になります。企業も次第に、開発やクラウドアプリケーションのアーキテクチャーにマイクロサービスを採用するようになっています。Talend Open Studio for ESBを使用して、マイクロサービスを構築する方法をぜひご確認ください。