「Microservices Meetup vol.2」行ってきたメモ。

http://microservices-meetup.connpass.com/event/36394/

登壇者はFitbit装備が義務付けられる様子……。


「マイクロサービスとSREの役割」by 鈴木氏 @kenjiszk (株式会社FiNC)
---

https://speakerdeck.com/kenjiszk/maikurosabisutosrefalseyi-ge

SRE = Site Reliability Engineering

サービス増える→サーバー増える→サーバーごとの設定等の同期が大変←つらい

サービスごとにSRE担当貼り付けたい→リソース足りない→担当できる人増やしたい

Dev/SREでキレイに分けるんじゃなくて、垣根は低く担当業務はクロスオーバーする

とはいえ、分ける部分はあるよね。
DBのパスワードとか。


「SRECon 2016 Wrap Up」by 坂本氏 @takus (スマートニュース株式会社)
---

https://speakerdeck.com/takus/number-microserv

n億行を秒単位で返す druid.io

SmartNewsには海外カンファレンスのチケット、ホテル代を負担してくれる神福利厚生（自主渡航制度）がある。

マイクロサービスは当たり前
netflix, uber, ...


### NetFlixの例

190ヶ国を5人のSREで担当している

Freedom & Resonsibility

開発者全員がシステムを壊せるくらいの権限を与えられている

誤操作で壊さないのか？
→SREがツールを提供、ミスしやすいツールは使えない

Spinnaker デプロイツール
デプロイ後に一定時間ロールバックできる仕組みを自分たちで作る

社内向けツールでもプロダクト開発のつもりで作る

### SmartNewsの場合

社内PaaS

* 社内の課題を見つける
* ドッグフーディングする

自分が導入したxxxが使いやすいのか日々自問自答している

### Uberの場合

udestroy
自分たちで自分たちのシステムを壊すツールを作る

めったに起きないことには時間を割きにくい

壊して止まるサービスにはしない

良い習慣を自然につくる

* Chaos Engineering : 定期的に壊しにかかる
* デプロイして問題があったらロールバック
    * どんどんデプロイして欲しい

### Googleの場合

* 50%ルール
    * 球拾い的な仕事を50%やらない、50%超えるなら働き方を変える


「マイクロにしすぎた結果がこれだよ！」by 榎本氏 @mosa_siru (株式会社Gunosy)
---

http://www.slideshare.net/mosa_siru/ss-64839846

* リソース単位でスタックを分ける
* スタックをまたぐ通信はAPIで
    * ガチガチめにマイクロサービスな設計

### マイクロサービスにした理由

writeタイミングを見合わせたり、バッチタイミングをずらさないと行けなかったり、手で変なデータ入れられてたりした。
DBディストピア

OpsWorksで管理されていたのでやりやすかった

でもやり過ぎた

* 45個のリポジトリ
* 30のワーカー
* ピタゴラ装置も出来てしまった

### デメリット

* 全体構成が複雑になる
    * 機能追加で3レポジトリ更新したり
* 開発速度が遅くなった
    * やらないといけないオーバーヘッド処理が多い
* 障害児の調査範囲が広い（わかりにくい）
* オーバーヘッドが大きい
    * スタックまたぎが増える
    * リソースの融通がしにくい
* 共通部分の更新で10とか20デプロイ必要になる
* APIのIF更新が辛い
* 管理画面を作るのが辛い
    * DBアクセスのためにもAPI経由するべき
    * 管理画面のためにCRUD APIを作った


DBディストピアを防ぎたいだけならマイクロサービスではなく、アーキテクトが必要だった？

### メリット

* DBディストピア防止
* 影響範囲が局所化
* 制約のために学びがあった
* メンバ追加が容易に
    * 全体把握しなくても参入できる
* スケールしやすさを得た

デメリットが目立つが、スケールすることを考えると再評価が必要

### まとめ

* マイクロサービスは組織論
    * 大きくなった時に効いてくる
    * 新規事業ではオーバーヘッドが大きい
* 状況に応じて分割粒度を見定める
    * （原理主義にならない）


「Microservicesの実際と対策」by 大谷氏 @shot6 (株式会社 ファーストリテイリング)
---

Bisiness Logicにまつわる6つの要素

Queue, View, REST, File, Notification(Email/Push), Database(RDB/NoSQL)

### 技術的な話

* AWS + Azure (マルチクラウド→しんどい)
* Jenkins
    * 100サーバ→トラフィック見て40サーバくらいに減らしてる
* Node.js
* elastic search (aws, elastic) + logstash -> kibana
* mesosphere
    * 先行的に試している
* KONG
    * API Gateway
* Slack
    * fab

### チーム的な話

技術的な面よりもチームの話が大事

* デプロイをパラレルで行うような大規模チームでないと効果が上がらない　
* リファクタリングはしやすい
* 十分な複雑さがないとペイしない
    * ビジネスライン
    * ステークホルダー
    * 変化への追従スピードを求められる
    * 投資できる

### マイクロサービスは体制が大事

* 専門スモールチームが必要
* ビジネス、開発、インフラ、アーキテクトが一体になってすすめるスタイル
* バックアップメンターがいると良い

### なぜマイクロサービスか

* 技術力のある数名で最大限に見る
    * 頭数揃えてもダメ
    * 技術を徹底活用して多くを見る
* アプリ開発からプラットフォーム開発
    * 意識を変える必要がある


* 運用面の懸念はまだ払拭されていない
    * 既存システムとの連携とか
    * データ一貫性の問題
* チーム編成に投資が必要
    * モノリシックの方がコストは安く上がる
    * アーキテクトの力が必要
    * 組織、カルチャーを変えられないならやめたほうがいい

* ビジネスマターではない共通な課題をどうするか
    * SREチーム的なものが必要
* 現時点で答えがあるわけではない
    * 海外では大手が人材獲得を進めている
        * Nike, Coca, GE, DowJones, ...

### 技術的な課題

* マイクロサービス間の通信
    * 可視化しないとわからない
* 依存関係の把握
* マイクロサービスのテスト
    * Dockerにすりゃいいわけでもない
    * コンポーネント間テストが難しい

ウェルネスタイム (大好評、FiNCトレーナーによるストレッチタイム)
---

HIIT
タバタプロトコル
4分で1時間の運動効果


「より良いAPIを作るために」by 相川氏 @awakia (ウォンテッドリー株式会社)
---

https://speakerdeck.com/awakia/yoriyoiapiwozuo-rutameni

[綺麗なAPI速習会](http://qiita.com/shimastripe/items/e9b0e1f8f8d77b89373f)

### インフラに求められること

* どんどんサービスを提供していきたい
* 新しい技術、Architechture使いたい

### Wantedlyの現状

* Dockerは1年半前から導入
    * Herokuからの移行
* OSはCoreOS


### マイクロサービスとは

2002年のAmazon社長が出した司令がわかりやすい

APIで全てを行えばよいっぽい

### wantedlyの仕組み

APIGatewayにKONGを使って集約している（KONGが必須パターン？）

BFF(Backends for Frontends)
シンプルなAPIサーバ(Go)をバックエンドにおいて、フロントエンドとの間にビジネスロジックを含むBFF APIサーバ(Rails, Node.js)をもう1段用意するのが良さそう

?fieldクエリ

* Facebookは?fieldクエリでだけ結果を返す
    * 通信量を減らしたいので必要なフィールドだけ返す

?preloadsクエリ

* 通常のAPIレスポンスはフラットなJSONで返す
    * 詳細情報が欲しい時に`?preloads=acccount`などとして、ネストしたJSONを返す

バージョン、メタ情報

* URLに/v1/とかするのではなく、Acceptsヘッダに持たせたり
* ページング情報もJSONじゃなく、ヘッダに持たせるのが流行

サーバジェネレータ作りました
https://github.com/wantedly/apig

まとめ
===

発表や懇親会で話を聞いた私の印象。

* (Microservicesは)ある程度規模が大きくないと旨味がない
* 高スキルなエンジニアを要する / 知見のあるエンジニアのフォローがないとつらい
    * 徹底した技術の活用を行うため
* 社内カルチャーから見直さないとうまくいかない（Microservicesは組織論）
* ネットだと（特に原理主義的な）記事が多いが、プロダクトレベルで実践している人ってあまりいないんじゃ？
* モノリシックとマイクロサービスの中間地点のどこかに最適解がありそう
* 大きな流れとしてはマイクロサービス化していく
* 外に出るAPIは[KONG](https://getkong.org/)でまとめておく