RubyKaigi 2014の知見。 Microservices について #rubykaigi

# RubyKaigi 2014の知見。 Microservices について #rubykaigi

## RubyKaigi 2014 における Microservices に関する話題
キーワードとして直接登場していたのは、
2014年9月20日の **「Ohayō Rails (おはよう Rails」** のパネルディスカッションの最中でした。
他の講演でも下記などは Microservices の構成要素と考えることもできます。

* [Continuous Delivery at GitHub](http://rubykaigi.org/2014/presentation/S-RobertSanheim)
    * GitHub社の継続デプロイの話
* [Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails](http://rubykaigi.org/2014/presentation/S-ToruKawamura)
    * Web API の話

## 前提
実際に Microservices を導入した経験はありません。
これから着手するシステムで段階的に導入予定です。

この記事の内容は既存の情報の糊付的な立ち位置になります。

## "Microservice Architecture" とは?
* 独立した小さなサービスの組み合わせでソフトウェアアプリケーションを設計する手法
    * 従来、ライブラリとして共通化していた部分を独立したサービスにする
* これらのサービスは独立してデプロイされる
* Web APIなどで連携する
* UNIXの設計哲学に基づく

## Microservices と従来の開発スタイルとの比較
### 従来の開発スタイル
* システムの変更が密結合
* 複数の役割が単一システムの中に混在していて、モジュール構造の維持や影響範囲の特定が困難
* スケール範囲が広い
    * 本当はシステムの一部のみをスケールしたい場合でも全体が対象になってしまう
* 技術レイヤーでチーム分割をしがち
    * 例えば [UIチーム、サーバーチーム、ロジックチーム] など
    * 小さな変更でも複数チームをまたぐためスピード感がない
    * [サイロ化](http://www.itmedia.co.jp/im/articles/0609/30/news018.html)し、全体として好ましい設計にならない
    * [コンウェイの法則](http://www.melconway.com/Home/Committees_Paper.html)
        * システムの設計は組織形態に引きずられる
* 開発チームと保守チームが別々
    * 部分最適による悪影響
       * 開発チーム => 納品だけ成功すれば運用のことは気にしない・・・等
* 領域が大きく、チームも職能で分断している
    * 開発者とユーザーの距離が遠い
        * 本当に求められるシステムとの差異が大きくなる
* 中央集権統治
    * 1つの技術に標準化しがち
        * 適材適所の技術選定ができない
* 集中データ
    * 1つのDB
    * ビジネスのコンテキストによって異なるモデルの表現の扱いが難しい

### Microservices
* 独立デプロイ
* 独立スケール
* モジュール境界が明確
* 適材適所の言語やDB選定が可能
* ビジネスに合わせてチーム分割
    * 職能の枠をこえる
    * UI・DB・プロジェクトマネジメント等、全域のスキルを要求される
    * ある製品を動作させる責任があり、各製品はメッセージバスを介して通信する
* 開発チームと保守チームの区別はなく、開発したメンバーがずっと面倒をみる
    * 全体最適になる
    * DevOps
* 領域を小さく分割し、チームもビジネス領域にあっている
    * 開発者とユーザーの距離が近い
        * システムに対する齟齬が少なくなる
* 分割統治
    * 適材適所で技術選定
        * 領域に適した言語、DB、etcを選択できる
* 分散データ
    * 別々のDB
    * コンテキストに合わせたモデリング
* 継続デリバリ、継続インテグレーション、自動テスト等インフラ自動化を必要とする

## Microservices 導入時の注意点

下記記事参照。
[microservicesに分割する際に注意するべき5つのこと](http://qiita.com/hirokidaichi/items/bf81f1f6f7ca3d694aae)

## 国内の Microservices 導入事例

下記記事参照。
[クックパッドとマイクロサービス](http://techlife.cookpad.com/entry/2014/09/08/093000)

## ワークフロー
徹底した自動化、効率化、いつでもリリースできるワークフローが必要になります。
ワークフローの例として、GitHub Flowについては以下。

[GitHub Flow 図解](http://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314)

## 課題
* 開発に求められるスキルの壁
    * [martinfowler.com MicroservicePrerequisites](http://martinfowler.com/bliki/MicroservicePrerequisites.html) 参照
        * Rapid provisioning ：迅速なプロビジョニング
        * Basic Monitoring ：モニタリング
        * Rapid application deployment ：迅速なデプロイ
* 呼び出しコストが高い
    * APIの粒度は粗くする
* 徹底した自動化
    * DevOps, ChatOps, Everything Automation
* 呼び出し失敗時の考慮
* ビジネスに合わせたチーム分割による知見の分散
    * チーム同士の知識共有の仕組み => Chat Tools, Qiita Team, Hubot など？

## 例
* システム構成
    * ワークフロー管理システム
        * ワークフロー管理
        * ワークフロー画像出力
        * ワークフロー帳票出力

### 従来構成
* 各システムは同一システム内のライブラリになっている。
* 担当は機能ごとにチーム分けされている

![monolithic.png](https://qiita-image-store.s3.amazonaws.com/0/43480/6909fb7c-4172-8ab3-982c-4c58d545c9fc.png)

### Microservices
* 各システムは同一した小さなサービスになっている。
* 担当はサービスごとにチーム分けされている

![microservices.png](https://qiita-image-store.s3.amazonaws.com/0/43480/3de761b2-97ce-b965-6418-744f10d45b17.png)

## 参考資料
* [martinfowler.com Microservices](http://martinfowler.com/articles/microservices.html)
* [martinfowler.com MicroservicePrerequisites](http://martinfowler.com/bliki/MicroservicePrerequisites.html)
* ["Microservices"を読んだ](http://deeeet.com/writing/2014/09/10/microservices/)
* [クックパッドとマイクロサービス](http://techlife.cookpad.com/entry/2014/09/08/093000)
* [microservicesに分割する際に注意するべき5つのこと](http://qiita.com/hirokidaichi/items/bf81f1f6f7ca3d694aae)
* [GitHub Flow 図解](http://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314)