読者です 読者をやめる 読者になる 読者になる

『マイクロサービスアーキテクチャ』とAzure Service Fabric 参加レポート #microsvc

イベントページ

connpass.com

スライド

docs.com

自己紹介

Microservices

  • Microserviceの言葉が出来たのは2011年5月
  • James LewisやMartin Fowler
  • Netflixなどが初期から採用
  • 日本ではクックパッドが初期に採用
  • Sam Newmanが2015/02に書いた
  • ガートナーのテクノロジートレンドにも登場

目次

  • 5章
    • モノシックなアプリをマイクロサービスへ
  • 6章
    • デプロイをマイクロサービスへ
  • 7章
    • テスト
    • E2Eテストをどうするか
    • プロバイダが変わった時にどうすれば
  • 8章
    • 監視の話
    • 複数のアプリへ行く時にどうまとめるか
  • 9章
    • セキュリティ
  • 10章
  • 11章
    • スケーリング
    • 障害について
    • 障害を隠蔽して全体のサービスをストップさせない
  • 12章

マイクロサービスの原則

www.slideshare.net

ModelledAroundBusinessDomain

Automation

  • 最初の3ヶ月は2つ、1年で10個、18ヶ月で60個に
  • どんどん自動化対象が増えていく

HideImpression

  • 実装の隠蔽を行おう
    • 悪い例
      • 同じDBにアクセスしてしまう
      • スキーマの変更が複数のサービスに影響を与える
    • 良い例はサービスの連結をする
  • 顧客とか製品とか、コンテキストが違うので、別々に持ちましょう
  • RDBの共有はやめましょう

分散

  • 全てのものを分散させましょう
  • 人々に自由を与えましょう
  • プログラミング言語・開発スタイルなどなど
  • GILT社は横軸が時間軸、リリース回数が右肩上がりであることが分かる

DUMB-PIPE, SMART ENDPOINTS

  • SOAはデータ管理などをパスで賢くする
  • マイクロサービスはMQのみ

Deploy Independently

  • サービスをどのようにデプロイするのか
  • HOSTあたり一つのサービスを進めている
  • サービスが2つあるときに、InventoryサービスからShippingExpectationsに沿って行っているかテストしましょう
  • コンシューマ駆動契約
  • Pact

Consumer First

  • SWAGGERを使ってサービスのドキュメントをAPI

SERVICE DISCOVERY

  • Hashcorpなどを使おう
  • HumaneRegistry
    • Wikiとかも使って

障害

  • 障害のシナリオ
  • Strangler App
    • レガシーアプリを一気に引退させるのではなく、インターセプトしてあげて行うのがStrangler Pattern
  • リクエストが全部落ちましたとかいう例の話
    • 徐々に速度が遅くなる障害があるアプリで発生
      • スレッドプールが全てそのアプリに
      • クライアントからのリクエストがいっぱい
    • タイムアウト時間を適切にした
    • スレッドプールを各レガシーアプリに持たせる
      • Bulkhead
    • 激しく遅くなるとリクエストしないようにする
    • 時々確認して正常になったらまたリクエストを送るようにする
      • Circuit Breakers

AGGREGATION

  • Elastic serachをする
  • 複数の場所にあったりするのをまとめよう

Azure Service Fabric

  • 今日時点ではプレビュー
  • クラスタ組んでる
  • Stateless and stateful
  • Replicationしつつ
  • 自動的に分散配置してくれる
  • アプリケーションのVersionUpにも使う