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

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

SRE = Site Reliability Engineering

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

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

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

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

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

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)

• リソース単位でスタックを分ける
• スタックをまたぐ通信は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 (ウォンテッドリー株式会社)

綺麗なAPI速習会

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

• どんどんサービスを提供していきたい
• 新しい技術、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でまとめておく