なんちゃってマイクロサービス化に備える①
プロダクションレディマイクロサービス 第1章 を読んだ
http://amzn.asia/9dxGbrJ
背景
自社で扱っているシステム(Rails4.2 / モノリス) の継続的開発が限界に近づいてきたため。
3行でまとめると以下のような状況でした。 - オブジェクト志向もくそもない、依存しあった密結合のclass達....。(なんでもかんでもModelクラスに書いた人がかつている) - 複数のビジネスを1つのモノリスで管理していたため、ビジネスAの変更がビジネスBに影響をもたらし大変なことに....。 - そもそもテスト書いてないところが結構ある。
この状況を打破するために、 「リプレースをしよう！！とチームは決意しました。 大事にすることは以下の2つ。 - 機能ごとに最適な技術を使えるように - 機能ごとの依存性を排除して疎結合にする。
結果「なんちゃってマイクロサービスでいってみよう！」という結論に至りました。
プロダクションレディマイクロサービスのまとめ
"なんちゃってマイクロサービス"を始めるために重要な章は、 第1章: マイクロサービス 第3章: 安定性と信頼性 の2つであると判断しました。 したがってこの2つの章をまとめます。
本記事では、まず第1章についてまとめます
第1章
なぜマイクロサービスか?
- 垂直・水平スケーリングが容易
- 小さく独立したコンポーネントにすることで、コード複雑性の排除
- 開発スピードが向上 - 新しい技術が取り入れやすくなる
マイクロサービスに用語の定義
1つのマイクロサービスは3つのコンポーネントを持つ
フロントエンド(クライアントサイド)
HTML/CSSのことではない。 静的なAPIエンドポイントのことを指す。 他のマイクロサービスから、リクエストがAPIエンドポイント(RESTまたはThrift)に送られる。
バックエンド
DBへの格納
データベースへの読み書きリクエスト
マイクロサービスエコシステムの4層構造
レイヤ4: マイクロサービス レイヤ3: アプリケーションプラットフォーム レイヤ2: 通信 レイヤ1: ハードウェア
レイヤ1: ハードウェア
ようわからん
レイヤ2: 通信
選択肢は2つ
1. HTTP + REST / Thrift
安定性、信頼性が高い 同期型(ブロッキングがある)
2. メッセージング
- パブリッシュサブスクライビング
- リクエスト・レスポンス形式
レイヤ3: アプリケーションプラットフォーム
以下を抽象化、自動化すのは必須 - セルフサービス内部ツール(共通で使うmodule的なもの) - テスト、ビルドの自動化(CIツール) - デプロイパイプライン - ロギングと監視(第6章にて詳しく)
組織的な課題
逆コンウェイの法則
コンウェイの法則: システムのアーキテクチャはコミュニケーションと企業の組織構造で決まる。 Microsoft, Google, Amazonなどで実証されている。 ↓ これの逆が「逆コンウェイの法則」である。 つまり、 マイクロサービスアーキテクチャを使っている企業の組織構造は必然的に小さくなる。 ↓ 1人1人が極端に専門特化してしまう。 マイクロサービスは孤立した形で開発をするのに、独立して機能しているチームが密に協力をしなければならない。 目標設定(OKR, KPI)などの設定・運用に大きな影響が出る。
技術的スプロール
スプロール: 都市の無秩序な拡大 1000チーム → 1000種のデプロイ方法、1000種のモジュール、100種の言語生まれる。 企業全体でのある程度の標準化が必要。
技術的負債が目に見えない形で溜まっていくことが多い。 ある日突然あるシステムが別チームのシステムに影響を与え、そのコードはすでに密に他のコードと絡みついていたら........。
障害の種類の増加
増えます。自明ですね。以上。
リソースの奪い合い。
これは自明だけど、よく考えた方がいい。 リソース戦略は必須。
