Microservices Meetup vol.2参加レポート

2016年8月9日、株式会社FiNCで開催されたMicroservices Meetup vol.2に参加してきた。
Microservicesってバズワードになっているわりに、これまで実践している人の話って聞いたことがなかったのだけれど、この勉強会では実践している人たちの話をたっぷり聴けて、本当に勉強になった。参加してよかった。
当日のメモを公開する。

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

  • マネージャー。

What is Microservices?

What is SRE?

  • Googleを発端として、インフラの人が名乗りだした。
  • 新規にやること以外はこの部署がやりますよ、みたいなイメージ。
  • SREが独立しがち。

Microservices x SRE

  • サーバの種類が多い
  • Microserviceは増える
  • SREネックになるのでは？
  • Microserviceにすると、Railsとか一個一個対応しなくちゃいけなくて辛い。
  • 1マイクロサービスに1SRE張るのも現実的じゃないしなー。

対策案

  • 業務開発チームに任せてみる

SRE育ててみた

  • 注意すべきは、セキュリティなど、SREの本質的な部分はSREで守らないといけない。

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

  • druid.io

SmartNews

  • モバイルに特化
  • スマニューには半年に１回海外の空気に触れさせる制度がある。

SRECon

  • Freedom & Responsibility
  • Netflixでは開発者に、サービスぶっ壊せるくらいの権限を与えている。
  • ぶっ壊されたらどうするの？=>開発者は変なツール使わない。 SREが作った、安全なツールがいけているから、何も言わなくてもそれ使う。

社内PaaS作った

  • 社内の課題を見つける
  • プロトタイプを作る
  • 最初の顧客を見つける

障害に現実感を持ってもらう

  • めったに起きないことに時間を割きにくい
  • 計画的にぶっ壊す。
  • Chaos Engineering
  • この辺り、うまくゲーミフィケーションの設定しようぜ。 -　障害発生時にbotにコメントしておくと、botがレポートにまとめてくれる。

SRE should be a Enabler, SRE should not be a Servant

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

KDDIと連携して作ったニュースパスの話

  • コンポーネント分けて、権限ガチガチに分けた。

  • セキュリティグループ見れば

  • OpsWorksはラーメントッピング感覚でサーバ作れる

  • 全体構成が複雑

  • 開発が遅い
  • 障害時の調査範囲が広い ボトルネックの把握が難しい
  • オーバーヘッドが大きい 余ったリソースを融通しあえない
  • 共通部分がしんどい
  • 内部APIのIF変更が辛い モノリシックの辛さをレイヤーを変えて味わっているような感覚。。。
  • 統合管理画面がやばい

良かったこと

  • 影響範囲は局所化できた。
  • メンバー追加のハードルが低い。
  • 今のところデメリット多いけど、人が増えたら再評価されるかも。

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

  • AWSで働いてたら、作りたくなった。
  • ヘキサゴン
  • Queue, Database, Notification, File, REST, View
  • AWSの機能フル活用している
  • マルチクラウドは辛いので、どっちかに寄せたいという気持ちがある。
  • APIはSwagger。
  • elasticsearch。logstashをbeatsに置き換えたい。
  • MESOSPHERE。
  • KONG。
  • マイクロサービスは技術重要じゃない、組織、体制の話。
  • 並行開発しないなら効果出ない。
  • マイクロサービスは要件に十分な複雑さがない限りペイしない。
  • モノリシックの方が絶対的に安い。
  • CRUDのAPI全部作る、いやいややりすぎでしょ、はあるある。
  • ZIPKIN。Twitterが作っているツールがある。
  • Microservicesのテスト難しい。

ウェルネスタイム

  • HIIT（High- intensity interval training）
  • タバタトレーニング
  • 椅子にお尻をちょんとつけるスクワットを20秒やって、10秒休む。これを8セット。計4分。
  • これで１時間の有酸素運動と同じ効果。

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

  • 綺麗なAPI速習会
  • Wontedlyは生まれた時からHerokuだった。
  • WebはAngular, Reactでできるだけシングルページアプリにして、API通信する。
  • BFF(Backends for Frontends)
  • SEOの問題で、Nodeがいいと思っている。
  • FacebookはAPI力入れている。
  • eager loadみたいな形で作っている。
  • APIのバージョンはヘッダに入れる。
  • apig。みんながCRUDのAPI全部作るの！？と言っていたところ、DBのスキーマ情報から作るようにした。

まとめ

Infrastructure as CodeやImmutable Infrastructureは、基本実践したほうがメリットがあるので、頑張って実践しよう、という感じで盛り上がっていたと思う。
それに比べるとMicroservicesを実践する/しないをしっかり見極めないと、メリット出なそうと思った。
理解しきれていない部分も多かったが、Microservices実践している人の話を聞けて、Microservicesが単なるバズワードから現実感のあるものになった気がして、本当にモチベーション上がった。 togetherはここ。