システム開発

March 27, 2020

アーキテクチャ

microservice

AWSでのマイクロサービスアーキテクチャ各社事例にみる取り組み方

microservices architecture 1

テクノロジーの力で新しい価値を創造するため、DXの推進が重要だと言われる昨今。

IT業界ではその取り組みの一つに マイクロサービスアーキテクチャ が挙げられる。

ネット上には色んな事例が溢れているが、個人的な結論としては 多くの組織にとって、マイクロサービスはオーバーエンジニアリング であり、軽いノリでやり始めても成功の確率は低いと思われる。

しかしマイクロサービスで語られる話は、アーキテクトを考える上で役立つ内容が多いため、今回はマイクロサービスに取り組んでいる他社の事例を調べ、私なりに実現方法を考えてみた。

ちなみに世界的なテクノロジー企業や大手メガベンチャーで、本格的なマイクロサービス開発に携わった経験は無いので、あくまで机上の空論になっております（あしからず）

マイクロサービスを考える上での参考文献

マイクロサービスとは何か!? どのような技術スタックが必要になるのか!?

次に紹介する2つの本には、マイクロサービスに関する話が網羅的に紹介されている。

マイクロサービスアーキテクチャ

posted with ヨメレバ

SamNewman/佐藤直生オライリー・ジャパン 2016年02月26日頃

posted with ヨメレバ

クリス・リチャードソン/長尾高弘インプレス 2020年03月

楽天ブックス

Amazon

Kindle

これからマイクロサービスに取り組もうとお考えの方は、どちらも目を通すのが望ましい。

ホントは推薦図書がもう一冊あるが、英語版のみなので割愛する。

マイクロサービスとは何か!?

まずオライリー本では、マイクロサービスの定義を次のように説明されている。

マイクロサービスは協調して動作する小規模で自律的なサービスであり、各サービス間の通信はネットワーク経由となる。そのためサービスを適切にモデル化(ドメイン領域の分割)、API定義を行い、デプロイの対処(クラウドやコンテナ技術)、テスト、監視などの知見も必要となる。

この文章を読んだくらいで理解できる方はそう多くないと思うけど…

AWSで紹介されているアーキテクチャ構成を見ればイメージが湧くだろうか。

microservices architecture 2

細かい話は次の文献に詳しく説明されている。

■ AWSにおけるマイクロサービス
■ コレ１枚でわかるマイクロサービス･アーキテクチャ

モノリスな開発に慣れている方は困惑するかもしれないが、なぜマイクロサービスなのか!?

理由は色々あるが、モノリスな環境で開発を続けてるとコードが複雑になり、メンテコストが膨らむ傾向にある。またインフラ面でも柔軟なスケーリングが難しいと言われている。

またオライリー本では、マイクロサービスのメリットを次のように言っている。

1. 技術特異性 (サービス毎に適した技術が利用可能)

2. 回復性 (障害部分のみ切り離し可能)

3. スケーリング (高負荷部分のみサーバー増強可能)

4. デプロイの容易性 (デプロイ時間短縮)

5. 組織面の一致 (小規模チームによる生産性向上)

6. 合成可能性 (機能の再利用)

7. 交換可能にする最適化 (小規模なので必要に応じて書き換え可能)

機能単位に独立したチームで運用するため、生産性向上が見込め、ビジネスチャンスが広がる（と世の中的に言われております、そんなに上手くいくかは会社によると思うけど…）

どんな知識・スキルが求められるのか!?

ではマイクロサービスの実現には、どんなスキルや知識が求められるだろうか?

まずマイクロサービスに限った話ではないが、当然ながらシステムに対するドメイン知識が必須。

また既存ドメインの適切な分割が求められ、その上で役立つのが DDDの考え方 だと言われる。

エリック・エヴァンスのDDD本を読んだことがあるが、私の理解力が乏しく、一度読んだくらいでは理解出来なかった。他の方に聞いても、いまいち分からん … 一部のシリコンバレーエンジニアの間では「DDDなんて知らん♪」と言う人までおり、この点は探り探りやるしかないらしい。

技術的な領域も幅広く、クラウド技術に精通したDevOps/SRE的なポジション、フロントエンドではReactやVueでのSPA開発経験、癖があると言われるサーバレス技術など色々。

開発者視点では上のいずれかに精通し、その他の技術は多少知ってるレベルで良いかなと思う。

サービス分割の方法

モノリスサービスをどの粒度で分割していくのか!?

具体的な分割について、マイクロサービスパターン本では2つが紹介されていた。

一つ目が Decompose by buisiness capability の業務に対応させてサービスを定義する方法。

二つ目が Decompose by sub-domain のドメイン駆動設計に基づく分割方法。

正直この本を読んだくらいでは、理解力の乏しい私は理解ができなかったけど…

マイクロサービスの欠点

システム開発に銀の弾丸は存在しないと言われるが、マイクロサービスにも当然欠点がある。

1. サービスの適切な分割方法を見つけるのが難しい.

2. 分散システムは複雑であり、開発 / テスト / デプロイが難しくなる.

3. 複数のサービスにまたがって使われる機能のデプロイには綿密な調整が必要.

4. いつマイクロサービスアーキテクチャを採用すべきかの判断が難しい.

また 分散システムの落とし穴にも気を配る必要 があり、次の記事が参考になった。

■ マイクロサービスを蝕む負の力学

サービス間の依存関係が複雑になり、通信コストやレイテンシー問題、機能単位にDBを保持するとデータの整合性問題も考えられ、十分な開発リソースや知見を持つエンジニアがいないと手が出せない。

何から手を出せば良いのか!?

やらない理由ばかり並べても仕方ないため、最後に仮にやる場合はどうすれば良いか考えた。

最初の取っ掛かりとしては、次の事例が参考になるかと思う。

■ ドメイン駆動設計パターンを使用してモノリスからマイクロサービスへ@Microsoft
■ マイクロサービス化デザインパターン@Graat
■ 実ビジネスのためのアプリケーションモダナイゼーション＠Graat

主に次の流れに沿って、段階的にマイクロサービス化していく。

1. モノリスへの機能の追加を停止.

2. フロントエンドからバックエンドを分割.

3. モノリスを分解し、一連のマイクロサービスを分離.

これは ストラングラーパターン と呼ばれる手法で、切り出せる部分をAPIとして分割し、第二段階でフロントエントとバックエンドを分割していくと説明されている。

AWSホワイトペーパーが足りない情報を補記してくれる役割を担っている。

■ AWSにおけるクラウドネイティブモダンアプリケーション開発と設計パターン

第三段階をどこまでやるかは、現場毎に悩むしかないといったところか。

その他の事例について

[ Microsoft ]
■ 破損対策レイヤーパターン
■ マイクロサービスでの API ゲートウェイの使用
■ ストラングラーパターン

[ Line ]
■ 実践マイクロサービス ─ コンポーネント分割やトラブル回避の考え方をLINEの導入事例に学ぶ

[ NGINX ]
■ マイクロサービスの紹介

[ Cookpad ]
■ クックパッドとマイクロサービス
■ クックパッドにおける最近のMicroservices事例
■ Service Mesh and Cookpad
■ 大きなRailsアプリケーションをなんとかしよう。まずは計測と可視化からはじめよう
■ クックパッド基幹システムのmicroservices化戦略〜お台場プロジェクト1年半の軌跡〜
■ 100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順
■ AWS 導入事例
■ How Microservices are linked at Cookpad

[ freee ]
■ freeeのマイクロサービス基盤とWire導入
■ AWS導入事例
■ OSSを活用した、マイクロサービスアーキテクチャの課題を解決する取り組みとは
■ Kubernetes×AWSで複雑化したマイクロサービス基盤を改善
■ Kubernetes on AWS/EKSベストプラクティス
■ gRPCでインターフェースを再整理してからサービスを分割─freeeの段階的なマイクロサービス戦略

[ ドリーム・アーツ ]
■ マイクロサービス・コンテナに全面移行するにはどうすればいいか?

[ zozotown ]
■ ZOZOTOWNマイクロサービス化 - API Gatewayを自社開発したノウハウ大公開！

[ RAKUS ]
■ マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト

参考記事