今注目のマイクロサービスアーキテクチャに関するセッションも多数
Spring Day 2016では近年注目を集めている「マイクロサービスアーキテクチャ」に関するセッションも行われました。Springとマイクロサービスアーキテクチャの相性の良さからでしょうか、事例や最新技術の紹介など様々なセッションがありました。本稿ではその中から4セッションを紹介します。
セッション「Let's Visualize Your Spring Cloud Applications! ～ElasticsearchとSleuthを使った可視化の実際～」
マイクロサービスは柔軟性が高く変化に対応しやすいアーキテクチャとして、いま注目を集めています。しかし、「サービスの数が増えてサービス間の依存関係が分からなくなってしまった」「各サービスのログが分散していて素早くログを確認することが困難になった」など、システム全体の把握が難しくなるという問題もはらんでいます。
Acroquest Technologyの谷本 心さんは、この問題の対策として「Spring Cloud Applicationを可視化する」方法をこのセッションで講演してくださいました。
講演ではデモを交えながら、主に次の3点について解説がありました。
サービス依存性の可視化：各サービスがどのサービスを呼び出しているかなどの依存性を一目で確認
変化に強いマイクロサービスにおいて、サービス間の影響が分からずサービス改修に時間がかかるという事態は避けたいですし、導入するべきだと感じました。
ログの可視化：アプリケーションログやアクセスログを可視化して見やすくすることで想定外の事象が発生していないかを確認
谷本さんはログの集計軸を後から変更できる点を強調していました。最初にログを取り込み、後から集計軸を決めて分析することが可能になります。また、ログが出力されないと思っていた集計軸で出力されて、想定外の事象が起きていることを発見した、ということもあるようです。
システムリソースの可視化：サーバやプロセスの状態を可視化し、システムが安定稼働しているかを確認
システムリソースの可視化は一般的に行われていると思います。しかし、谷本さんはログ情報とシステムリソース情報を並べて確認できることがポイントだといいます。複数の情報を並べて確認することで、今まで認識していなかった問題に気づける可能性があるそうで、このことはとても印象的でした。
そのほか、可視化システムが落ちて情報が欠落しないように、可視化システムの安定化を図る話などもありました。可視化により、マイクロサービスをより良いものにできると感じたセッションでした。
これからマイクロサービスを導入される方は「可視化」について検討してみてはいかがでしょうか。
セッション「Microservices Architectureを超大規模プロジェクトでやってみた -一筋縄ではいかない苦闘の一年間-」
マイクロサービスはその実現に高度なスキルが必要とされ、国内での成功事例はまだまだ少ないといえます。このセッションでは、ワークスアプリケーションズの三宅泰裕さんに、自社製品をマイクロサービス化した苦闘の過程をお話ししていただきました。
ワークスアプリケーションズでは、ERPシステム「HUE」をSaaSとして提供しています。かつてのHUEは巨大な1つのSpringプロジェクトであり、ビルドだけで14時間、WARファイルの動作には32GBのメモリが必要という状態だったそうです。
それを三宅さんは、巨大なプロジェクトの分割に向けた依存関係の解決や、分割後のサービスのビルドやデプロイに取り組んで改善。最終的に分割されたモジュールは5～40分程度の並列ビルドが可能となり、最大メモリも1～4GBに抑え込むことに成功しました。
三宅さんはこの経験を踏まえ、「マイクロサービスへの移行は確かに難しいが、技術的に実現は可能である。むしろ重要なのは精神面での改革だ」といいます。
技術的な勘所を学べただけでなく、パラダイムシフトを組織として許容できることが、技術論と同等以上に重要であると感じることもできたセッションでした。
セッション「災害対策（DR）対応の超ミッション・クリティカル Cloud Foundry は Azure!!」
このセッションでは、日本マイクロソフトの寺田佳央さんがMicrosoft Azure（以下、Azure）上にPivotal Cloud Foundry（以下、Cloud Foundry）の環境を構築した、マイクロサービスのアプローチについて説明してくださいました。
セッションの前半は、AzureとCloud Foundryを用いてタイムリーなサービスリリースに取り組むFord社の事例紹介。昨今、IT技術の進歩は目まぐるしく、次々に新しいサービスが世の中に出てきています。その中で、歴史ある自動車会社であるFordも本業の自動車事業だけでなく、新しくIT部門を立ち上げ、ITサービスに注力しているとのこと。ユーザーの望むサービスをタイムリーに提供できるように、変化に強いマイクロサービスのアプローチをとっているそうです。
セッションの後半では、障害を想定して「サーキットブレーカーがどのような振る舞いをするか」や運用後の負荷変更を想定して「スケールイン・スケールアウトをどのようにするか」を、実際の操作（デモ）を交えて説明されました。
なお、Azureの場合、他のクラウドベンダーよりも多くのデータセンターを保有しており、災害対策に優れたアプリケーション基盤をCloud Foundryを用いて容易に構築することができるとのことです。これからのAzureの発展やCloud Foundryとの更なる連携を期待していきたいです。
セッション「Data Microservices with Spring Cloud Stream, Task, and Data Flow」
Pivotalの槙 俊明さんのセッションでは「Spring Cloud Stream」「Spring Cloud Task」「Spring Cloud Data Flow」という３つのプロジェクトが紹介されました。これらは組み合わせて使用することで真価を発揮します。それぞれの役割は次のとおりです。
- 継続的に流れてくるメッセージを処理するためのアプリケーションはSpring Cloud Streamを用いて作成
- 呼び出されたときに起動し、処理が完了したら終了するようなアプリケーションはSpring Cloud Taskを用いて作成
- Spring Cloud StreamやSpring Cloud TaskのアプリケーションをSpring Cloud Data Flowでオーケストレーション
Spring Cloud Data Flowは、ビッグデータ処理用途で開発されていたSpring XDのアーキテクチャを刷新し、Cloud FoundryやKubernetesといったモダンなプラットフォームに適応させたものとなっているそうです。 Spring Cloud StreamやSpring Cloud Taskのアプリケーションは、通常のSpring Bootアプリケーションにアノテーションを加えるだけで実装可能といい、非常に簡単であるという印象を受けました。
また、データのフィルタリングや加工といった処理をそれぞれ小さなアプリケーションに分割して行うため、各処理をを個別にスケールアップ／スケールアウトできます。この点で、マイクロサービスと共通する性質を持っているようです。そのほか、スケールアウトした際に同じメッセージが全てのノードに流れてしまうことや、同じノードで処理すべきメッセージが別のノードに振り分けられるのを避けるための機能を備えていることも解説されました。
比較的新しいプロジェクトであり、対応メッセージングサービスの拡大や機能改善も予定されているということですので、今後の動向にも注目しましょう。
