ITコラム

マイクロサービスの実装における考慮点

記事をシェアする:

クラウドネイティブなアプリケーション実装における考慮点
インフラやソフトウェア・プラットフォームのサービス提供として始まったクラウドは、その後コンテナに代表される仮想化技術の進歩や、テスト自動化などのツールチェーンに支えられた継続的デリバリーの実現により、アプリケーションの開発スタイルそのものを変えつつあります。クラウドを活用することで迅速に開発でき、処理増加に対するスケーラビリティーを持ち、コンテナ上であればどこでも稼働することができるクラウドネイティブなアプリケーションへの移行を、多くのお客様が検討しています。
このブログでは、クラウドネイティブなアプリケーションのスタイルとして特にフォーカスされることの多いマイクロサービスの構築を始めようとしている方々へ、構築の際に直面しがちな設計後の実装上の考慮点などを紹介します。

1. マイクロサービスの実装における考慮点

設計が終われば、次は実装となります。システムをマイクロサービスで構築することにより、ビジネス変化へ 素早く対応するための変更リスクを低減できる反面、以下の考慮が必要となります。

耐障害性の考慮
モノリスなシステムの同一プロセス内でのサービス呼び出しに比べ、マイクロサービスのネットワークを介したリモート呼び出しは、対象マイクロサービスのプロセス停止やハングアップ、過負荷など、失敗する可能性が高くなります。また、複数のサービスに依存したサービスの信頼性は、その乗算となり、マイクロサービスを複数経由する分、モノリスなシステムと比べて信頼性が劣ります。このため、一部のサービスのプロセスダウンやスローダウンによる影響が、サービス全体に及ばないようにするため、サービス呼び出し側で、耐障害性を高めるための対策が必要となります(Fault Tolerance)。

運用の自動化、ツール化
マイクロサービスのシステムは、複数のサービスによって成り立っているため、監視や障害対策、リリースの運用もサービスごとに行う必要があります。サービスが増加するにつれて、従来の方式では運用負荷が高くなるため、運用負荷を低減する対策が必要となります。障害時はできるだけ自動復旧するよう、各サービスの監視、ダウンした際の自動リカバリー、高負荷時の自動スケーリングが必須の機能となります(Health Check、Auto Healing、Auto Scaling)。

モノリスなシステムでは、一つのシステムの状態を確認しさえすれば、障害時の調査、サービスの状態を把握することができました。しかし、マイクロサービスのシステムでは、すべてのサービスの状態を確認する必要があります。数十、数百のサービスのログや、サーバーの稼働状態を人手で調査するには大変な労力を要します。このため、マイクロサービスでは、各サービスのログを収集し、分析できるサービスが必要となります(Distributed Tracing、Metrics、Log Collection、Log Analyze)。
本章では、Fault Tolerance、Distributed Tracing の実装について説明します。

1-1. Fault Tolerance

他のサービスをリモート呼び出しする際、呼び出し側 のサービスは、以下を考慮した設計、実装とする必要が あります。

Timeout
同期処理でのマイクロサービス呼び出し時、呼び出し先のマイクロサービスが過負荷やハングなどで応答が返ってこない場合、呼び出し側のマイクロサービスも応答を待ち続ける状態となり、エンドユーザーへ応答が返らずハングしているように見えます。後続の処理も同様に対象サービスの応答待ちとなるため、呼び出し側のサービスもハング状態になり、影響が連鎖的に全体に及びます。適切な時間内に応答が返らない場合は、タイムアウトするようにし、全体がハングしないようにします。

Circuit Breaker
一般的に、処理内容やシステム状態によりシステムのレスポンス・タイムは変化するため、タイムアウト値を「レスポンス・タイムの期待値+予備時間」とするのが一般的です。また、タイムアウト値を設定していたとしても、一部のサービスが一時的な過負荷によりスローダウンした場合、タイムアウト待ちのスレッドでサーバーのリソースが占有され、他の要求を処理できなくなります。このため、一定の割合で呼び出しが失敗したサービスに対しては、一定時間そのサービスへの要求は行わずにエラーとし、不必要なリソース占有状態を回避します。一定時間経過後に一部対象のサービスに要求を送信してみて、正常処理が確認できたら通常状態に戻し、正常処理が確認できなければ再度そのサービスへの要求は行わないよう制御します。

Bulkhead
タイムアウトしないまでも、呼び出し先のサービスがスローダウンした場合には、呼び出し元が応答待ちのスレッドで占有されてしまい、サービスが提供できなくなってしまいます。ある一つのサービスのスローダウンがボトルネックとならないよう、サービスごとに同時呼び出し数を制限し、影響を局所化します。

Fault Toleranceの実装は、OSS(Hystrix)や製品な どライブラリーが多数提供されているため、スクラッチで開発する必要はありません。「IBM WebSphere Application Server Liberty」(以下、WAS Liberty)で はMicroProfile Fault Tolerance 1.0仕様に準拠した フィーチャーを提供しています。MicroProfileは、Java Enterprise でマイクロサービスのアプリケーションを開発するための共通仕様です。また、Hystrix、 MicroProfile共に、呼び出すマイクロサービスごとにクライアントを作成、Fault Toleranceの設定が必要ですが、AIF(API Integration Framework:WAS Liberty 上で稼働するIBMアセットのJavaフレームワーク)では、 一つの汎用的なクライアントを提供しており、設定のみでFault Toleranceを実現可能です。

1-2. Distributed Tracing

エラーやスローダウン発生時には、あるサービスから呼び出された複数のサービスの処理結果および処理時間の データをリアルタイムで可視化し、障害時のリードタイム を短縮することが必要です。このためには、各マイクロ サービスが実行された際に、実行されたサービスの処理情 報と処理時間を、これらの情報を収集するためのサーバー(分散トレースサーバー)にリアルタイム送信します。分散トレースサーバーは、Zipkin、JaegerといったOSSで 構築が可能です。各マイクロサービスから分散トレースサーバーへ送信する機能は、同じくZipkin、Jaegerが提 供するクライアント・ライブラリーを使用し、各マイクロ サービス側で実装する必要があります。WAS Libertyで は、MicroprofileのOpenTracing 1.0仕様に準拠したフィーチャーと、そのフィーチャーを使いZipkinに情報 を送信するサンプルを提供しています。さらにAIFを組み合わせ、Zipkinへ送信する情報にAIFが対象リクエストを実行したログの追跡IDを付与し、アプリケーション・ログとのトレーサビリティーを強化しています。

上記ではコンテナ内のアプリケーション、ミドルウェアによる実装方法を記載しましたが、「IBM Cloud Private」上でKubernetesを使用した構築マイクロサービスを実装する場合、待望のバージョン1.0がリリースされた「Istio」を導入することで、アプリケーション自体に手を入れることなく、Fault Tolerance、Distributed Tracing、Metrics、Log Collection、Log Analyzeの 機能を実装することができます(図1)。

図1. IBM Cloud PrivateとIstioを用いたマイクロサービス実装例(ログ分析サービスを内包)

図1. IBM Cloud PrivateとIstioを用いたマイクロサービス実装例(ログ分析サービスを内包)

このように、マイクロサービスの実装構築には、その欠点を補うための手段が必要であり、IBMではこれらを提供するアセットの開発とOSSの利用による対応を行っています。こちらで記載していないマイクロサービス構築に必要となる機能、Health Check、Auto Healing、Auto Scaling、Metrics、Log Collection、Log Analyzeについても、IBMアセットとして、設計ガイド、実装ガイドを作成中で、2018年内にリリース予定です。

おわりに

以上、マイクロサービスの構築時に、設計・実装面で直面する課題への取り組みについて紹介しました。冒頭で述べたようにマイクロサービスは仮想化や自動化技術の進化を取り入れながらも、過去のソフトウェア工学が築いてきた進歩の先へ向かうものの一つであり、これからの展開が望まれています。

マイクロサービスの構築を始めようとする際に、直面する課題に対する考慮点についてはマイクロサービス構築を始めるにはーークラウドネイティブなアプリケーションの設計で解説します。

 
「クラウド先進技術を活用してイノベーションを加速する」あらゆるアプリケーションをサポートするアジャイル・アーキテクチャーとクラウド・ネイティブなアプローチで開発者を支援します。

 

松本 龍幸 Tatsuyuki Matsumoto

日本アイ・ビー・エム株式会社 グローバル・ビジネス・サービス事業部 クラウド・アプリケーション・サービス.MSA&モダナイゼーション 担当 シニア・アーキテクト/コンプレックス・エンタープライズ・アーキテクト
1993 年日本 IBM 入社。金融業、製造業のお客様を中心にホスト基幹系からWeb 基 幹系まで大規模システム構築を主体として、アーキテクトとしてアプリケーション基盤 の構築や開発手法の適用に従事。現在はクラウドの提案とデリバリー適用を担当。

大和田 弘成 Hironari Ohwada

グローバル・ビジネス・サービス事業部 クラウド・アプリケーション・サービス.API&インテグレーション ITスペシャリスト
2002年日本IBM入社。金融のお客様を中心にWebアプケーション開発案件のシステ ム構築に従事。ホストGWシステム開発などを経て、現在は、APIシステム構築の提案、構築支援、APIアセットの推進を担当。

More ITコラム stories
2019年4月2日

Kubernetesを軸に再定義されつつある、新しい「クラウド対応」の意味とは

このエントリーをはてなブックマークに追加 著者:新野 淳一氏 ITジャーナリスト/Publickeyブロガー。 […]

さらに読む