マイクロサービスアーキテクチャについて

マイクロサービスアーキテクチャについて

下記の書籍を読んだ際のまとめになってます。
マイクロサービスアーキテクチャ

 

マイクロサービスとは?

強調して動作する小規模で自律的なサービスのことを指します。
「2週間で書き直せるもの」「十分に小さく、ちょうどいいもの」などとも言われていたりいます。

以下の説明とかもわかりやすいかもしれません。

マイクロサービスは、「疎結合」と「高凝縮性」を特徴とし、サービスの境界をビジネスの境界に合わせ、特定の機能のコードがある場所を明確にします

下記記事より引用
マイクロサービスアーキテクチャのまとめ(メリット/デメリット/用いる技術)

 

マイクロサービスを使用するメリット

【技術異質性】
サービスごとに異なる技術を採用することができます。
新たな技術も容易に試すことができます。

【スケーリング】
スケーリングさせたいサービスだけスケールさせることができます。

【回復性】
障害が起きても、すべてのサービスを止める必要がなく、障害が起きている箇所のみに対応できます。

【デプロイの容易性】
変更を加えた箇所だけデプロイすることができます。
問題が生じた場合は、迅速にロールバックすることができます。

【組織面の一致】
アーキテクチャを組織と一致させることにより、サービスの所有権をチームに移し、作業する人数を最小化し、チームの大きさと生産性を最適化することができます。

モノリシックアプリケーション

分割されていない一つのモジュールで構成されているアプリケーションのことです。
よくマイクロサービスと対で使われる言葉なので、メモっておきます。

 

サービスのモデル化

優れたサービスは、2つの特徴を持ち合わせています。

【優れたサービスとは?】

疎結合

システムの他の部分を変更する必要なしに、あるサービスを変更してデプロイできることです。

高凝集性

関連する振る舞いは1箇所に存在することです。

【境界づけられたコンテキスト】
うーんこれがあまり自分の中では理解できていない。
有名なDDDの本に出てくる概念らしいけど、あまり理解できていない。
DDDでは、すべての人(ソフトウェアエンジニア、ドメインエキスパート)が同じ言葉で言葉を使うことがゴールのようだが、
そもそも大規模になってくると、そんなことやってると費用対効果が低くなってしまいます。

そこで出てくるのが、境界づけられたコンテキストです。
コンテキストを分割することで、コンテキスト内で用語を統一できるようになります。
境界付けられたコンテキスト 概念編 – ドメイン駆動設計用語解説

 

統合

マイクロサービスの中で一番重要だと言われているのがこの「統合」という箇所です。
その中で重要な箇所だけピックアップしました。

データベースの統合を避ける

絶対にデータベースの統合は避けましょう。
統合することで、マイクロサービスの特徴である疎結合、凝集性の両方を失うことになるためです。

コレオグラフィを使う

コレオグラフィを使用するというのが、本書では著者の主張になっています。
オーケストレーションを使用するデメリットとしては、中央集権的になってしまうことが挙げられます。
基点となるサービスが他のサービスを制御するイメージ。

 

デプロイ

マイクロサービスのデプロイは、複雑になる可能性があり、痛い目を合う可能性が高いです。

CI

マイクロサービス1つごとにCIビルドを持つことが推奨されます。

Dcoker

コンテナ技術といったらこれですね。
軽量コンテナ上に構築されたプラットフォームです。
また複数のマシン上の複数のDockerを管理したい場合は、「スケジューリングレイヤ」が必要になります。
この際によく使用されるのが、「Kubernetes」「CoreOsのクラスタ技術」です。

デプロイツール

Terraformとかがよさげ。

自動化

まあいろいろ書きましたが、自動化を目指しましょう。
そして人間が集中すべき課題解決に集中できるようにしましょう。
ココらへんは、DevOpsにも出てくる考え方ですね。
そのためにも自動化を可能にする技術を選定することが重要です。

 

感想

いやー勉強することが出てくる、出てくる…..
今回まとめた他にも「テスト」とか「監視」とかありますが、それらに関する記事はぜひ次回ということで!

 

参考にした記事

Airbnbの事例に学ぶKubernetesとマイクロサービスのあり方 @ KubeCon Seattle 2018
マイクロサービスについてザックリとまとめてみる
マイクロサービスアーキテクチャのまとめ(メリット/デメリット/用いる技術)