「Microservices Meetup vol.4」に行ってきた

ブログ/Qiitaまとめ枠で参加させてもらいました！

Advent Calendar作ったから是非参加してね！（切実）とのこと。
http://qiita.com/advent-calendar/2016/microservices

あとから資料のURLとか補完しまーす。
→資料補完しました。

Togetter
https://togetter.com/li/1053879

発表まとめ

「AbemaTVにおける Microservices Architecture」 by 西尾亮太さん (CyberAgent, AbemaTV)

AbemaTVについて

無料で見れる24時間365日完全編成インターネットTV
https://abema.tv

PCもスマホもタブレットもTVデバイスも対応してます！

番組表がある（リニア放送）のが特徴です。砂嵐がないよ！

プレミアムプランならオンデマンド放送も見れます。

インターネットコンテンツとしての特性

• 視聴数リアルタイム表示
• コメント
• SNSシェア
• 投票

本開局から半年で1000万DL達成

アーキテクチャコンセプト

Microservice Architectureの物理的な難しさ

• スケーリング
• トレーシング
  • 分散で難しくなる
• リリース
• メトリクス
• テスト
• 監視
• ロギング
• LB
• サービスディスカバリ
• 低遅延

基本的にスケーリングに紐付いて各要素が難しくなる

メリットは享受したいがデメリットは避けたい

実質4ヶ月の開発期間

答え：GCP + Kubernetes + gRPC

Google Cloud Platform

Microservicesに便利な機能が揃っている

• Cloud DNS/LB/CDN
• Strage/Bigtable/Datastore/SQL
• Container Engine
• Container Registry
• など

Kubernetes

• OSSなのが高評価
  • ベンダロックインされないところを重視した

gRPC

RPCの一種

• Unary RPC
• Server steaming RPC
• Client
• Bidirecional streaming RPC

を含む。

Metadataを持つ

Protocol Buffers 3 + HTTP2をデフォルトとする←ココが大事

関連プロジェクトとして grpc-gateway がある。
RESTful JSON APIをgRPC定義から生成してプロキシサーバとして使う

インターネット配信に必要なコンポーネント

WEBアプリとしての

• FrontEnd
• BackEnd
• Cache
• Database

と、動画制御の

• Live Encoder
• Transcoder
• Packager

の組み合わせ。

サービスの役割

• Gateway
  • クライアントにAPI提供
• User
• Media
• Comment
• Share

これらのサービス間で協調することでコメント投稿を行っている。

コメント欄が荒れることを想定して有人監視システムを入れて、ユーザの点数付けも行っている

というのが興味深い。

スケーリング

Kubernetesで

リリース

Container Registry + Kubernetes + CircleCI + カナリアリリース

プロダクトリリースは1Podだけリリースして問題なければ全体に適用（カナリアリリース）

メトリクス

Stackdriver + Kubernetes + Prometheus

• Prometheusが便利！
  • 各PodにPrometheus用のEndPoint
  • Annotationつければ勝手にやってくれる

ロギング

Cloud Logging + Cloud Pub/Sub + Kubernetes

Podの標準出力はCloud Loggingに自動収集

大事な運用ログは自前で保管分析するためにPub/Subに流して内製システムに流している

ロードバランシング・サービスディスカバリ

Kubernetes + Service +　（あとで補完）

低遅延

gRPC + Cloud Pub/Sub

ProtcolBuffers / HTTP2

• ProtcolBuffers
  • 空間効率に優れる
  • エンコード・デコード高速
• HTTP2
  • イケてる
• Cloud Pub/Sub
  • 滞留しても期間内なら自動復旧してくれる

アーキテクチャの例外と復旧

破綻したアーキテクチャ

永続化エンティティに対して管理ツールが直接アクセスしている。

本来は管理ツールもサービスを経由してアクセスしないといけない。

• 何故起きたか。
  • チームがtoCチームとtoBチームに分かれていた。
  • 表に見えるサービスと管理ツールの納期が違っていた。
    • 管理ツールが2ヶ月早く必要だった（ただでも4ヶ月だったのに……）
• 対症療法
  • エンティティに対してWrite出来るサービスを固定した
  • 新しいものは正しくサービス経由でアクセスするようにした

まとめ

• 完全完璧は目指しても難しい
• 負債の管理と整合性を取ることが大事

質疑

• AWSは検討しなかった？
  • 検討したけど、コンテナ使おうとするとベンダロックインが多少あった
  • AWSはちょっと飽きてた（会場笑い）
• GCP東京リージョン出来たけど移行した？
  • 現在移行計画策定中
    • やっぱり台湾でも遠い
  • ただし東京リージョンは高いので慎重な検討が必要と思ってる
• 動画配信だとアウトバウンド課金あると顧客増えると課金大変じゃない？オンプレミスのほうが良かったんじゃない？
  • コスト面ではその通り
  • 目標はインターネットのテレビ局を作ること
    • クオリティ考えてAkamai以上のクオリティを担保できると判断できなかった
• Microservices化挑戦して戻した経験があるけど、現状で良かった点悪かった点あれば
  • 以前はAPIのエンドポイントが500ほどあるサービスを経験したが、リリース時に関係者の調整が大変だったからすごく楽になった
• 開発規模はどの程度だったか
  • サーバサイド9名
  • インフラ3名
  • クライアント6名
• Microservicesを浸透させたか
  • 上手く行かなかった
  • そもそも難しいものを使っている
  • 一部のメンバが判断して開発を進めた

「Our Experience Bridging Monoliths Using Microservices」 by Yves-Eric Martinさん (MediWeb, 3Bees)

http://www.mediweb.jp
http://www.3bees.com

日本語上手！

モノリシックなアプリをMicroservice化した経験の共有

6プロダクトを提供

• Bee診察予約
• Bee順番予約
• Beeメッセージ
  • 「薬が切れたらまた来てください」とかのコミュニケーションをサポート
• Bee患者満足度調査
  • 口コミ系のサービス
• Bee業務日報
  • 医者は医療のプロだが、ビジネスのプロではない
    • 毎年数千件も倒産している
  • 病院のビジネスをサポートする
• Bee患者受付Asura
  • 受付機をクラウド連携で実現するサービス

今の規模

• 10つのWEBアプリ
• 3つのモバイルアプリ
• 2つのオンプレミスシステム

AWSとかHerokuを使っている。

Gitレポジトリが30を超えた
レポジトリ数課金のサービスを使うときに辛い

4,000のクリニックが利用している

エンジニア数は5.2人？ 0.2人はMartinさん自身のこと :-)

サービスの経緯

4つのWEBアプリでスタート

それらは独立したモノリシックなシステム

当時は医療データは国内に持たないといけなかった。
AWSもHerokuも使えなかった。
法律が変わってしまうとサービスが止まるため統合できなかった。

ユースケースとしても同時利用されにくいと考えていた。
診療予約と順番予約とか。

創業者が医者なので、ユーザテストが念入りに行われている。
使いやすいものを作ったため、複数サービスを使う人が増えてきた。
独立したシステムだと使いにくく感じてきた。

そして患者情報はクリニック内にしかない。

挑戦を始めた

システム間で通信できるようにした。
もともとバックエンドでCOBOLが動いているようなシステム。

仲介するためのオンプレミスなマイクロサーバを構築。

その後、RESTfulなAPIを提供してブラウザから患者情報を取得することが出来るようになった？

カルテID連携サービスを構築。
機微情報を利用者のブラウザでのみ扱うように（サービス内に持たずに済むように）JavaScriptで取得するように設計した。

順番待ちリストはあるけど、個人情報がないから何人並んでいるかはわかるけど誰が並んでいるかはそもそも情報がないので隠匿される。
（カルテIDだけでユーザ管理を行うってことかな？）

Microserviceと意識せずに構築していた。

運用を始めたら

順番待ち一覧の取得で20秒とかかかった

Multi-getsで解決、10秒以上かかっていたのが480msに。

railsは標準だとシングルスレッドだから、パラレルアクセスできるようにTyphoeus）というライブラリで対応した。

デッドロックが起きた

開発中は気づかないが、実運用では20インスタンスで動くので発生した。

リリース当時は気にしていなかったが、ある日突然発生した。
3回くらいサービスが完全停止した。

バックグラウンドでロードせずに、ブラウザロードでデータ取得するようにして解決した。
（メモ者注：聞き間違えている気がする……）

まとめ

Pros

• どことどこが連携するのか明確にする
  • どこからでも使えるようにしようとするとスパゲッティコードになる
• 機能ごとに独立したリリースが出来るようになった！うれしい！！

Cons

• 難しい（20%〜50%増しで手間がかかっている）
• テストとエラーハンドリングが難しい
• 変更（リファクタリング）が難しい
  • 他のサービスとつながっているため
  • 変更時は1まとめのPRにまとめたいけど、リポジトリをまたぐ……
• 開発者の初期設定が難しい
  • サービスの数だけセットアップしないといけない

質疑

• リリース時どうしてる？ 共通gemとか。
  • 必要なときは一気にリリース
  • TDDでやっている
  • でも人手でのテストも行っている
    • 共通機能をコピペ実装するよりは共通gemの方がいい

ウェルネスタイム

「今日はきつめで！」

• ジャブ10秒
• フック10秒
• スクワット10秒
• はやめスクワットたくさん

FiNCメソッド

「野菜から食べて少し時間を置いてから、メインディッシュを食べる」

スポンサートーク FiNC

• ヘルスケアベンチャー企業
• 規模
  • エンジニア約30人
    • うち外国籍8人

FiNCのマイクロサービス

約15個

• FiNC App
  • バックエンド
• Wellness Survey
• FiNC Mall
  • EC
• Online Works
  • 食事指導など、専門家とユーザをつなぐサービス

技術

• Rails
• AWS
• Docker, Amazon ECS
• Front-end Server : Node.js, GraphQL

マイクロサービスだから新しい技術に挑戦しやすい

面白いところ

• 上手くサービス境界を設計できると運用しやすく、上手く設計できないとかなりきつくなる
  • 設計超大事
  • 夜中の3時位まで飲みながら設計について喧々諤々することもある

エンジニア募集中！

「マイクロサービスっぽい感じの話」 by 春山誠さん (DeNA, Sakasho)

(参考 : http://www.slideshare.net/blueskyblue/dena-sakasho)

挑戦した反省点の話

ゲーム開発のプラットフォーム

• Sakashoはゲーム開発コンポーネントのうち汎用性が高い部分のコンポーネント

Sakashoとは

• ネイティブゲーム用プラットフォーム
• ネイティブゲームのサーバサイドに必要な機能すべてを持つ
• 運用し安さを見据えてある程度制限を課す
• Unity, C++のゲームエンジンに対応するためのSDKを持つ
• 課金とかPush通知とか
• WebViewインタフェースの提供
  • お知らせ、掲示板、利用規約など
• ゲーム専用サーバとの連携機能
  • 認証とか
• マスタデータ配信とかアセットとか課金、ログ、お知らせ、などなど

マイクロサービスっぽい？

SDK - Proxy - APIs(10種1台ずつ) - Sakasho DB - 管理ツール

レスポンスは50msec.を確保

役割ごとに10の独立したAPIコード群（＝リポジトリ）
各チームが独立して動ける、規模変更も容易

でも共通機能gemは辛い

構成に大事なこと

• 独立性の確保
• インタフェースの取り決め
  • REST / AMQP(Advanced Message Queuing Protocol)

重視したこと

• サービスが落ちることは避けたい
• 凍結した部分には極力触りたくない

発生した課題

• サービスごとにデータの隔離がされていない
• ロジックが独立していない
  • 共通gemのアップデート問題
• チーム体制は1チーム8〜10人で開発運用が続きおもったよりもスケールしていない

人数に対してサービスが分かれたので大変になった

ロジック間共通のgem問題

例）プレイヤーデータの保存と報酬受取を1トランザクションにしたい

sakasho-common_modulesが生まれた→設計上良くない

なぜこうなった

• 一貫性を重要視し、不整合起きないようにした
  • 同一トランザクション
• チートさせたくない
  • ロジックをサーバに寄せることになる

反省

状況

• コードベースを整理
• サービスが分かれててわかりにくい
• チーム規模が小さい
• サーバリソース
  • 32GBメモリで100くらいのプロセスでリソース空きが多い

こうしていきたい

• 一旦コードを1つにまとめる
  • 管理のしやすさ
  • サーバーリソースは余裕
• 仕様が変わらないことを保証するために結合テストを準備

現時点でココまでやった

• 上期にSDKのテストを強化
  • googletest採用（C++のテストフレームワーク）

今後こうしていく

• 粛々とコードベースをまとめている
• マイクロサービスからモノリシックに戻している
  • 管理コスト削減が狙い
  • 整理してからまた改めて考える

DeNA Tech Conやります。
https://techcon.dena.com

質疑

• ゲームプラットフォームなら速度必要だけどRubyよりも他の言語の方がよかったりしないです？
  • 遅いかと思ってたら50msec切ってるから特に問題ないので、言語変更は考えてない
• トランザクションを確保したいのであれば、ブロックチェーンの仕組みで上手くやることは出来ない？
  • DeNAの強みとしてMySQLの運用実績があるので、インフラ面はそれに乗っかっている
  • ミドルウェア周りでもっといろいろ出来ると思うがまだ投資できていない、これから考えていくところ

LT1:「マイクロサービスの辛さ その① 起動時編」 by @yudppp さん

HAROiD Platform

• テレビ連動プラットフォーム（リモコンのDボタンとか）

扱うプロジェクト数が増えた。

一日3から5プロジェクト起動する。もともと作ってないものも含めて。

プロジェクトによってタスクランナーが違ってたりする。
面倒くさい！

→タスクランナーマネージャー作った！！ yudppp/tsks

見慣れぬプロジェクトで設定されているタスクコマンドを一覧してくれるツール。

★つけてくださーい。

LT2:「Auth0を使ってサインインを一括管理したり Azure Functionsをセキュアにしたりした話」 by @ovrmrw さん

もっともお手軽なマイクロサービスは「クライアント-Firebase」じゃない？

DBとしての機能がしょぼい
遅い

Firebaseで完結するとは思えなかった
でも機能は便利

別のDBサービス(Cloudant)を組み合わせてみた

Client<->Cloudantで認証キー持たせるの？いやだなぁ。

Client<-> WEBサービスはさむ？ <->Cloudant

両方からサインインするのやだなぁ。

Auth0使ってみた。

AzureFunctions(AWS LambdaのAzure版みたいなの)

Auth0を使ってFirebaseにも認証状態にする。

JWT(JSON Web Token)は汎用的な仕組みらしいのであちこちでつかえるっぽい。

Azure Functionsにセキュリティを確保しないといけない。
Auth0で割りと簡単にできる。

これらをやるとAPIがどんどん増える。なんとかするためにGraphQL登場。

GraphQLについては時間がないので資料紹介のみで。
http://qiita.com/ovrmrw/items/d3db8fd0374f10219914

感想

• Microservice化はどこの事例でも「多人数＜＜＜＜精鋭数人」での開発
• 今回のウェルネスタイムよりもvol.2の方がキツかった
• マイクロサービス化のPros/Cons/注意点にある程度傾向あるっぽい
  • Pros
    • リリース楽になる
    • 振る舞いを変えないリファクタリングが楽になる
  • Cons
    • 管理大変（チームで分かれないとキツイ）
      • 組織がスケールすることが前提
    • サービス境界の仕様変更が大変
    • 共通モジュールのデプロイが大変
  • 注意点
    • サービス境界切り分けに高スキル設計者が必要
      • 担当エンジニアは量より質
    • サービスを分けすぎると辛くなる
    • モノリシックで作って、大きくなった部分をマイクロサービスとして切り出すのが現実解っぽい
      • DDDがココで効いてきそう