「マイクロサービスで、一歩先行くImmutable Infrastructureを目指そう」参加レポート #jtf2015

JTF2015 勉強会 技術

スライド

www.slideshare.net

発表者のブログ

oshiire.to

自己紹介

  • しょっさん
  • 「よくここのアイコンとここの名前でここに来たもんだ」

今回の発表について

  • 紹介ページが他の人と比べておかしい
  • 色々訳あってスポンサーすることになって会社名を出せない
  • 抽象的な話ばかりになっちゃうことになる
  • 期待と違いがあったら「最悪だった」と言ってください

今日の内容

  • 明らかに人を呼びこむタイトル
  • 今日の発表の主体はマイクロサービスではなくSevice Oriented Architecture(SOA)の話

Immutable infrastructure

  • 既存のものはそのままにしておいて、新しいものは使い捨てできるようにしよう
    • 日本だけしか流行っていない

Blue Green Deployment

  • 新しいものはGreenに入れよう
  • ある程度揃ったら切り替えれば簡単だよね
    • 元ネタのブログは最近は絵が変わってた

Issues

  • しかし現実は様々な問題がある

1. Stateless and stateful services

  • Statelessなサービスは、情報が無くなっても良い（問題ない）
  • DBサーバーはどうするのか？
    • ある程度の更新を止めるのか
    • DBは別の方法にする？
  • 単純なシステム構成なんて無い

2. Complex System

  • サーバーのやり取りが複雑すぎる
    • 銀行のサーバーを一度見てみると良い
    • 青い銀行はいっぱい募集している
      • 今なら三行分のシステム構成が見れる
  • 交換するときの影響度が把握できない

Microsevices

  • 2014å¹´3月に提唱
  • James Lewisが提唱しているが、Martin Fowlerのブログで書いている

特性

  • いっぱい特徴がある
  • コンポーネント化
  • プロダクト（プロジェクトではない）として提供
    • プロジェクトのように、1回作って終わりではない
    • 開発した人が責任をもって運用し続ける
  • スマートエンドポイント
  • コンポーネントを簡単な手順で結びつけろ
    • RESTを使う（同期）
    • Message Queueing（非同期）
  • 分散して統治する
    • 自分達で責任をもって管理する

コンポーネント

  • 役割分担とインターフェースの明確化
  • 活性保守の仕組み作り
  • メモリはコンポーネントの一つ
    • マザーボードに指す順番が決まっている
    • メモリを変えれば、メモリのサイズを上げられる
    • インターフェースは変わっていない
    • インターフェースが明確でないとこんなことはできない
  • コンポーネントを使う人は変更を知らなくて良い
  • 「機能が削減された」「ロジックが変わった」はダメ
  • コンポーネント化すると、コンポーネント単位で区切れるので、コンポーネント毎に切り替えられる
  • マイクロサービス化されていれば、ステートレスなサーバーに、インターフェースが変わらない保証があれば、適用できる…はず

Microservicesを始めてみよう…どうやって？

  • 日本は既にマイクロサービスしやすそうなところばかりが事例として載っている
  • 欧米の紹介はよくわからない

僕達にはSOAがある

  • SOAのコンセプトがだいたい一緒
  • 事例もある
  • SOAの事例を使えば、Microservicesにも使えるのではないか
  • 外国ではSOAの話題が更新され続けている

アプリケーションフロントエンド

  • エンドユーザーとの対話部分
  • バッチなどからコールされるプロセス
  • 人とかプログラムの境界部分

サービス

サービスレポジトリ

  • 提供されているサービスの情報を集約
  • 使う人が分かるように

サービスBUS

  • 接続性、技術、通信概念の混在
  • 技術的なサービス
  • 各々のサービスをBUSを通じてコミュニケーションしよう

SOAの目的

SOAとマイクロサービスの比較

  • SOAは集中、マイクロサービスは分散
  • SOAは集中→分散管理、マイクロサービスは分散管理
  • SOAは大企業向けトップダウン、マイクロサービスは中企業向けボトムアップ
  • 企業の規模、企業の風土に合わせて適用することが大切

SOAロードマップ

  1. 基礎段階：保守性の向上
  2. ネットワーク化整備：柔軟性の向上
  3. プロセス制御段階：俊敏性の向上

基礎段階

ネットワーク化段階

カプセル化
テクノロジゲートウェイ
  • ECサイト、配送システム、B2Bポータルと別々の入力があっても中堅層を通じて基本層に行う
中堅層を使えるようにすると
  • データの拡張
  • 引き継いだモデルを変更せず、レガシーアプリケーションのデータモデルを拡張
  • パッケージに対して機能を拡張する
  • 既存のプロトコルを維持、新たなクライアント機能を追加

プロセスの制御

  • プロセスのカプセル化
  • ECサイト→予約プロセス→会員、受注・在庫の中堅層→受注、在庫
  • 単純化
  • プロトコルが要らなくなってきたら中堅層をなくしていく

中堅層の考え方

  • 複数のプロセスが利用する場合に中堅層を作る
  • プロセスの中心化

プロセスの中心化

  • なぜプロセス化したいのか
  • 簡単にプロセスを組み合わせて新しいサービスを提供したいから
  • サービスもUIもあれば、プロセスを作れば簡単になる
  • セッションを長時間維持するためにもある

summary

  • サービス化：疎結合→影響の極小化
  • 適合可能な技術の選択
  • 新しいものと古いものを組み合わせる
    • 新しいものが全て良いとは限らない
    • 古いものが悪いとも限らない
  • 車輪の再発明はしない
  • 再利用しよう
  • Re-usable But Re-cycle
    • はじめから再利用しようと考えるものと、あるから使おうは違う
  • 流行に流されないようにしよう
  • SOAをもっと知りたい人は『SOA大全』を読もう

SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針

SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針

感想

  • マイクロサービスではなくSOAの話でしたが、すごい楽しんで聞くことができました
  • 「マイクロサービスとSOAって何が違うの？」と聞かれると言葉に詰まっていましたが、腑に落ちる説明でありがたかったです
  • メモリの話とか分かりやすかったです
  • SOAのロードマップとかRe-usableの部分とか、設計をしっかりと考えることが大切だと改めて感じたセッションでした

JTF2015講演まとめ

nihonbuson.hatenadiary.jp