TaNA LABO
エンジニアリング

March 27, 2020

AWS
GAFA
DX
マイクロサービス

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

post 29

テクノロジーの力で新しい価値創造するため、デジタルトランスフォーメーション(DX)の推進が叫ばれているが、その取り組みの一つに マイクロサービスアーキテクチャ が挙げられている。

個人的な結論では、求められる技術領域も広く、多くの組織ではオーバーエンジニアリングであり、何となく流行っているからやってみよう♪的な軽い勢いで手を出すと痛い目にあうと思う。


ただマイクロサービスで語られている考え方は、システムアーキテクトやサービスを考える上で有用なので、実際にマイクロサービスに取り組まれている事例含め、自分なりに色々と考えてみた。

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

オライリーの書籍では以下のような内容で説明されている。

マイクロサービスは協調して動作する小規模で自律的なサービスであり、各サービス間の通信はネットワーク経由となる。

そのためサービスを適切にモデル化(ドメイン領域の分割)、API定義を行い、デプロイの対処(クラウドやコンテナ技術)、テスト、監視などの知見も必要となる。

文字だけでは全体像が理解しづらいので、以下記事のアーキテクチャ図を見ると良い。

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

一般的なWebシステムでは、全ての機能(ユーザーインタフェース / ビジネスロジック等)が一まとまりになったモノリス構成となっている。リリース時は問題ないけど、長い間改修を続けていると、保守管理の工数も膨らみ、インフラの面でもスケーリングが難しかったり。

またビジネス環境が頻繁に変化している現代、従来のやり方では通用しなくなってきた。これらの課題を解決し、ビジネスをスケールさせるため、システム全体を互いに独立した機能部品に分割し、連結させて機能させるアーキテクチャの重要性が言われている。

post 29 1

ちなみにオライリーの書籍では、マイクロサービスのメリットを以下のように言っている。

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

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

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

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

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

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

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

独立した各機能は、APIでの相互通信(REST/gRPC)なので疎結合となり、また機能単位に小規模チームで運用するので生産性向上が見込め、ビジネスチャンスが広がると(分散システムには色んな落とし穴があるので、こんなに上手く行くとは思えないけど)

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

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

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

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

あとマイクロサービスの話が盛り上がる要因には 昨今のクラウド技術の発展 が大きいかなと思う。

例えば過去は困難だったインフラのスケーリング対応、分割された機能群同士を連携させるSQSやSNS等の登場、コンテナ技術(Docker/ECS/EKS/k8s)の発達、バックエンドとフロントエンドを分割する手法(S3/CloudFront)、各種サーバレス技術(Lambda)などあり、これらに精通することが求められる。

何かしらのクラウド技術(AWS/GCP/Azure)に精通したDevOps/SRE的なポジション、フロントエンドではReactやVueでのSPA開発経験、色々癖があると言われるサーバレス技術を使いこなせる人などは、採用のハードルが高い気がして厳しいのでは!?と個人的に感じる(GAFAや有名テック企業ではやれるんだろうけど、一般的なWeb企業ではちょっと現実的ではない気がする)

サービス分割の方法

ちなみに書籍(マイクロサービスパターン)では、モノリスなドメインの分割方法を2つ紹介している。

Decompose by buisiness capability では、業務に対応させてサービスを定義する方法。

ただ主要なサービスの一つ一つを他サービスと連携させ過ぎると、プロセス間通信が過度になり、非効率になるケースもあるため、場合によってはサービスを結合する判断も必要。

Decompose by sub-domain では、ドメイン駆動設計に基づく分割方法。

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

マイクロサービスの欠点

マイクロサービスでは主に以下のような欠点が挙げられる。

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

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

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

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

マイクロサービスでは分散システムの落とし穴にも気を配る必要もあり、こちらの記事が参考になる。

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

マイクロサービスでは、サービス間の依存関係が複雑になったり、通信コストが増える問題、機能間のレイテンシー問題、あと機能単位にDBを保持するので、データの整合性問題も考えられ、組織として十分な開発リソースや知見を持っているエンジニアが求められる(頭痛すぎる)

仮にやる場合はどうすれば!?

やらない理由ばかり並べても仕方ないので、仮にやる場合はどうすれば良いか調べてみた。

色んなテック企業が取り組まれているが、最初の取っ掛かりとして、以下事例が参考になると思う。

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

主に以下の流れで、段階的にマイクロサービス化していく。

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

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

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

ストラングラーパターン と呼ばれる手法で、切り出せる部分をAPIとして分割し、第二段階でフロントエントとバックエンドを分割していくやり方で、この点はAWSホワイトペーパーが参考になると思う。

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

第三段階をどこまでやるか(厳密にDB分割までする!?)は、現場毎に悩むしかないといったところか。

その他の事例について

■ 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の段階的なマイクロサービス戦略

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

参考記事

REST APIの設計で消耗している感じたときのgRPC入門
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴
マイクロサービス移行を阻むレガシーとの戦い方
おっさんがACIDとかBASEとかまとめておく
「メタデータ」「NoSQL」「CAP定理」を理解する
「マイクロサービスに出遅れた」ところは、先人から何を学べるか
マイクロサービスが注目される理由 導入検討に向けて気を付けるべきポイント
創業時はJava 1.3、JDBC、JSPで構築――ECサイト「Oisix」がマイクロサービス化を進めたワケ
マイクロサービスアーキテクチャにおける「サービス配置」の考え方
新規構築や移行時のリスクを軽減、「ストラングラーパターン」とは?
マイクロサービス移行を阻むレガシーとの戦い方
マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント
Kubernetes architecture
数時間で完全理解!わりとゴツいKubernetesハンズオン!!
KubernetesとNode.jsでマイクロサービスを作成する
Kubernetesの自前運用は難しい?はてなの撤退事例
AWS コンテナサービス「Fargate」「ECS」「EKS」の違いを解説
DockerでEC2、ECS、EKSの運用想定まとめ
AWSはなぜ、ECSがあるのにKubernetesのサービスを始めたのか、コックロフト氏に聞いた
コンテナーとは?Kubernetesとは?導入や運用、ユースケースを解説
今さら人に聞けないKubernetesとは?
Microservices Patterns を読んで(1)


©Copyright2020 TaNA LABO. All Rights Reserved.