Microservices Casual Talks パネルディスカッション参加レポート #microsvc

microsvc 勉強会 技術

イベントページ

connpass.com

モデレータ

  • 高井直人
  • みんなのウェディングCTO
  • 今日の話はちょっと厳しかったのでは？
    • 個々の事例を話すと細かい話になって自分のところに当てはまらない
    • アーキテクチャの話だと抽象的すぎて…

  • オライリーさんの本はよくわからない

  • 基本的に会場からの質問に答えていく形式

質問

  • 開発環境をするときに、依存するサービスを立ち上げなかったりしないとデータを入れていくとか面倒くさくなったりしないのか？

吉川

  • クックパッドでは動作確認環境がある
  • そこにdeployしたものをつなげたりする
  • 共通の環境に繋げる
  • データはどうするのか？（by 高井）
  • 共通のデータベースを使っている
  • プロダクションのSlaveを使うことで、ほぼ本番同様のものを使う

前板

  • canariaを使う
  • 本番に出る前に動作確認をする

大谷

  • AWSでは、大前提で個々でオーナーがはっきりしている
  • stagingとかがあって、パイプラインがあって、canariaでdeploy
  • プロダクションで、一つだけdeployして様子見してみるとか
  • development→stagingの環境

質問

  • localでの環境では開発しないのか？

大谷

  • なるべくDockerのイメージとかでできると楽

高井

  • コンピューティングは無料に近いのでいくらでも動かせれば良いじゃん

大谷

  • Netflixはシングル環境

前阪

  • 最近だとクラウド環境
  • 15インチのmac book proを担ぐのは辛い

質問

  • 1サービスのチームの規模、1マイクロサービスあたりのチームの規模、サービス間のコミュニケーションコストはどれくらいか。

大谷

  • GILTの話
  • チームを変更しないといけない
  • 5〜10人でマイクロサービスが100個とかを分けると破綻する
    • ここらへんが理解されづらい
  • AWSだとマイクロサービス毎のチーム
  • 全体を把握するのが難しい
  • 5人ぐらいが良い（two pizza ルール）
  • 200個とかのサービスに分かれたりすると、複数のマイクロサービスを束ねたりする
  • Amazonの基本的にはNo Meeting
    • APIに従うだけ
  • データベースのアクセスポイントは開発者に公開しない
  • 大きなプロジェクトは横串
  • お前のことなんか知らねーよ的なことになっている
  • 日本に合うかどうかは気になること

高井

  • アジャイルと近い考えで、やったことがある人とない人で理解が違うかも

吉川

  • チームによりけり
  • 2人や3人で1つのサービスを見ている
  • 基盤系のサービスの場合、4人で5つのサービスを見たりする

アンケート

  • マイクロサービスを運用している人
    • ちらほら

質問

  • deploymentの質問。1サービス1VM、EC2をいっぱい立てるとか、1VMに複数サービスを置くとか色いろあると思うが、それらに対してメリット・デメリットがあるか？

吉川

  • クックパッドだと環境によって分けてる
  • 本番環境の場合、1つのサービスにELBは1つ
  • テスト環境だと同居している
    • 同居することでリソースを食い合う
    • ただし、テスト環境ではそこまで気にならなければ、管理が複雑にはならない

高井

  • 如何にResirienceを確保するかを考えるときにMicroserviceが出てきたと思う
  • Availability Zoneが落ちても良いかどうかとか

前阪

  • それぞれの最適解が異なる
  • いきなり100点を求めることではない

高井

  • 組織の要求に合わせてプラクティスを考える

質問

  • UIレイヤーのサービス、複数のビジネスドメインが入っている時に、誰がUIを作るのか
  • 例えば、カレンダーとか検索とか複数のサービスで使ったりするが

大谷

  • AWSではConsoleが各サービス・チームで違う
    • 例えばS3とEC2で違う
  • AWSはUI/UXはすごい弱い
    • 最近は良くなってきている
  • 一つのマイクロサービスのデメリットとして、全体のUIを横串で通さないといけないが、それが難しい
  • APIごとで分かれると、利用者で使いづらい

前坂

  • UI/UXの専門チームがいる
  • 開発者がそこを触れることはない
  • JSON APIがスタンダードになると、UI/UXで変わらなくなる
  • 将来的にはemberになるのでは

吉川

  • クックパッドはフロントエンドからバックエンドまでやる
  • 横串のエクスペリエンスは、それ専門のチーム（ユーザーファースト室）がある
  • 原則はそこのチームが作ったフレームワークに乗っ取る

質問

  • 認証に関する質問。
  • 認証のレイヤはどこでどうするか

大谷

  • AWSは認証の部分のマイクロサービスでチームがいる
  • セキュリティのスキルがある人が頑張っている
  • 統一化するようにしていく
  • 業務から入ると難しいのかな
  • この部分の実装のスキルセットを持っていない時にどうしようとか

佐藤

  • Microsoft(Azure)では、REST API経由で
  • 認証用のサービスを作っている
  • 中の仕組みもOAthとか
  • 各サービスがAPIを呼んで認証する

高井

佐藤

  • Azureã‚‚1つのサーバーを共有している

吉川

  • 次期クックパッドの認証を社内で話している
  • コアになる認証を持って、全サービスが問い合わせる
  • 現状だと無理が出てきている
    • 固有のセッション管理とか
  • ユースケースが色々
    • 住所とかの個人情報と匿名性の高いもの
    • 会員とか、一見さんとか
  • 中央集権的な認証を廃止して、サービスごとに認証をdeligateする
  • 認証の要求レベルが変わる

質問

大谷

  • マイクロサービスで分けていくと、1 to 1のコミュニティは無理があって、10msが10個あると100msで成り立たない
  • 1by1でキューでやると成り立たない
  • イベントの入り口のところで必要なのは同期の入り口と非同期の入り口、エンドポイントに対してsubscribeする
  • 興味が有るところにsubscribeしておけば良い
  • 出口の部分がそのように連結している
  • 絵で書かないとここらへんの説明は難しい

質問

  • AWSの中でのmessagingシステムはどうやって？

大谷

  • 要件によって違う
  • AWSのメータリングは、30日後にバーンと出ていたりしていた。
    • これはReactiveではなかったから
  • 安全なドカン
    • 1日毎、30秒毎とかものによって違うが、順番通りに出ていることが大事
  • 非機能的な要件が結構ある

高井

  • 月次バッチや日時バッチがドカンになるということですね

質問

  • サービスの依存性の把握について
  • このサービスを止めたりすると、どこに影響が出るのか把握しにくくなるのでは？

吉川

  • Pactが呼び出し関係をグラフィカルにしている
  • Trace loggingでリクエストの流れを追ったり、呼び出し元からの流れ

高井

  • ソリューションとして出すのか？

大谷

  • GoのOSSである
  • シミュレーションの段階で予見できるのが大事
  • 前のコンポーネントに戻すときにそういうものが大事になる
  • dependencyのコントロールするものが必要になると思うが、世の中には浸透してきていない
  • 入り口と出口は把握しておく必要がある
  • ハンドメイドで大変になっている

佐藤

  • Azureは現状では手動管理になってしまっている。
  • Service Fabricでも現時点では無いので、今後に期待したい

高井

  • 運用者視点のものが多くて、アプリ開発者は気にしたくないが、気にしなくてはいけない