CNDT2020 High-Scale Architecture

F1e7eb88ee8989e5d642b111a2fa2343?s=47 makinoy
September 08, 2020

CNDT2020 High-Scale Architecture

F1e7eb88ee8989e5d642b111a2fa2343?s=128

makinoy

September 08, 2020
Tweet

Transcript

  1. 1 急速な成⻑を加速させるアーキテクチャ オープンテクノロジー・マルチクラウドの活⽤ Yuki Makino / CTO, PLAID ɹɹʛɹɹ© 2020

    PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ
  2. 2 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. 牧野 祐⼰ Yuki

    Makino • 東京⼤学⼯学系研究科修⼠ • IBMソフトウェア開発研究所 • 分散インメモリDB研究開発 • 並列プログラミング⾔語研究開発 • テキスト分析研究開発 • CTO, PLAID • 分散データ処理
  3. 3 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. ハイスケーラビリティのための アーキテクチャーとテクノロジーについて ”ハイスケーラビリティ第⼀主義”である

    PLAID の経験談
  4. 4 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ スケーラビリティー? 規模のスケーラビリティ 守りのスケーラビリティ

    ビジネスのスケーラビリティ 攻めのスケーラビリティ
  5. 5 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ なぜ PLAID は

    ”ハイスケーラブル第⼀” なのか? ”データにより⼈の価値を最⼤化する” という壮⼤なミッションを実現するため 組織と⽂化
  6. 6 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ アムダールの法則 S(N) =

    1 (1 − P) + P N 1εέʔϧ͢Δ෦෼ 1/ ͠ͳ͍෦෼ スケールしない部分の⼤きさの割合が スケーラブルかどうかに⼤きく影響する ߴ଎Խ 1/ ߴ଎Խ
  7. 7 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 基本スタンス: スケールしない部分の排除 ⼀番⼤事なリソース:

    ⼈の頭 ⾃分たちでやる事/考えることをなるべく減らす 作るところが増えるほど考えることが増える -> テクノロジー / クラウド を積極的に活⽤ その上で、 外部の道具の特徴と進化スピードを 最⼤限に使ってプロダクトを伸ばす -> テクノロジー / クラウドによる加速 組織と⽂化
  8. 8 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 使い分けを考える順 クラウドやOpen Technologyが中⼼

    になるような考え⽅ 使い分けの意思決定フロー 1. まずクラウドで実現できないか? 2. OSS / Open Technologyで実 現できないか? 3. 重要な部分だけ⾃分たちで作り 必要なら還元
  9. 9 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. ൚༻ ಠࣗ 4FMG

    0QFO $MPVE ͚ͩ͜͜ʹ 'PDVT ͳ͘͢ ϚϧνΫϥ΢υ ߈ΊͷΫϥ΢υ σʔλεέʔϧ)JHI ௕ظͷج൫ ʹͳΔ ݟۃΊ͕ඞཁ ͕͜͜ελʔτ zΫϥ΢υωΠςΟϒz
  10. 10 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. の取り組み

  11. 11 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc.

  12. 12 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. データ量 10+ PB

  13. 13 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ アーキテクチャの変遷 1. 初速

    2. 3.
  14. 14 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 加速 Phase.1 初速を出すこと優先

    やらないこと 不要な技術的深⼊りしない “HowよりWhy” 最適化/分割で制約を増やさない テクノロジーで加速 集約性と柔軟性によりスピードUP
  15. 15 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. User Interface Business

    Logic Data Storage +40/ +40/ ҙਤత.POPMJUI
  16. 16 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 黎明期 ポイント 可能な限りシンプルに集約

    柔軟性を優先 全てを JS とJSON に寄せる すべてシングルクラウド -> スピードUP ! 学び リポジトリ間のバージョン管理が 邪魔になりスピードDown 分割のさせ⽅が⼤事 ! !
  17. 17 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ドメイン⽅向に緩やかに 分割 ポイント

    アクセスパターンや 必要なスケーラビリティによって 緩やかにデータベースを分割
  18. 18 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ɹɹʛɹɹ© 2020 PLAID Inc. User Interface Business

    Logic Data Storage Data Storage Data Storage アクセスパターンで分離
  19. 19 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 縦に⾒てロールを分けない フロント /

    バックエンド コードと⼈を固定化しない 頻繁にドメインをスイッチ Why? ドメイン単位のスピードUP バックエンドをサービスに活かす 決まった⾃分の領域を持たず 全体プロダクトレベルの視点を持つ 組織と⽂化 User Interface Business Logic Data Storage Data Storage Data Storage Team Team Team 緩やかなドメインを縦にチームが⾒る
  20. 20 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ アーキテクチャの変遷 1. 初速を優先

    2. マルチクラウド 3.
  21. 21 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 加速 Phase.2 攻めのクラウドと

    マルチクラウド やらないこと ハイスケールな部分の運⽤/管理をしない 回避できないクラウドの障害と戦わない テクノロジーで加速 多様なクラウドプロバイダの強さを取⼊れ られる状況を作る 安定性の向上
  22. 22 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 攻めのサービス選択 ポイント 分割したデータベースの

    負荷が⾼い場所を ハイスペックなサービスへ置換え この辺りでクラウドをまたぐ 構成管理をスタート
  23. 23 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ マルチクラウドへ ポイント コアサービスを中⼼に

    どちらでも稼働できる形へ移⾏ Terraform, Packer, Spinnaker などのマルチクラウド対応のOSS を導⼊し構成管理、 デプロイ、 監視 に運⽤コストを下げる
  24. 24 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ さらに通信の整理 ポイント マルチクラウド間の

    DBレプリケーション Managed OSSで パブリックなエンドポイントを使う ⾃由に動かせるようになり 安定性が上がる 課題 構成が複雑化しアプリケーションと の乖離が⼤きくなり属⼈化が進む
  25. 25 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ ハイスケールアーキテクチャ への2ステップ 1.

    1桁先の守りの設計 柔軟性が⾼く枯れて安定した オープンテクノロジーを利⽤ e.g. MongoDB, Redis まずはできることを減らさないように 2. 2桁以上の攻めの設計 制約を⾜しハイスケールな クラウドサービス上に移す e.g. Bigtable 1. -> 2. で考えることを減らす ! 考え⽅
  26. 26 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ アーキテクチャの変遷 1. 初速を優先

    2. マルチクラウド 3. k8s で分散
  27. 27 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 加速 Phase.3 で集約から分散へ

    やらないこと 運⽤の集中、 属⼈化 サービスのための複雑な運⽤構築 テクノロジーで加速 各サービスの開発の⾃由度を上げる
  28. 28 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ サービスの数が どんどん増える

  29. 29 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ エンジニアも増える ը૾͕ೖΓ·͢

  30. 30 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ k8s の導⼊ ポイント

    リリースにより増えるサービスを 分散管理できるようになる より簡単にさらにサービスを 追加できるようになる 学び VM -> k8s 移⾏でサービス分離も 同時に進めたら時間かかった 全てを分散することはできない
  31. 31 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 再びマルチクラウド化 ポイント Publicエンドポイントで構成がシ

    ンプルになる サービス側でバックエンド クラウドを切り替えられる Managed OSSは マルチクラウドと相性がよい
  32. 32 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ 他も Container 化

    (Ongoing) ポイント Container運⽤が全デフォルトへ ただし負荷が⾼すぎてk8s化は できない 7. LT $POUBJOFS 0O 7. 5JNF (今ならk8sが デフォルト)
  33. 33 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ Self-Contained Systems ポイント

    分散させすぎず適度に集約する One Repositoryに複数のSystem 単体で完結するSystem SharedなCross Cut要素を残す 学び バージョン管理にはいまだに悩む Ref: https://speakerdeck.com/ komukomo/migrating-to-microservices 4ZTUFN 4ZTUFN 4ZTUFN 4IBSFE $SPTT$VUUJOH 'SPOU 4FSWJDF %BUB 4FSWJDF -PHJD 4FSWJDF 4FSWJDF REST API 3FQPTJUPSZ
  34. 34 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ Self-Contained Systems ポイント

    分散させすぎず適度に集約する One Repositoryに複数のSystem 単体で完結するSystem SharedなCross Cut要素を残す 学び バージョン管理にはいまだに悩む Ref: https://speakerdeck.com/ komukomo/migrating-to-microservices
  35. 35 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ Q. マイクロサービスは”善”か? A.

    善も悪もない、道具 マイクロサービスの解釈 : 分散化を”可能にする”技術 ”全てを分散化すべき”ではない パフォーマンス/組織や⽂化/知識 に合わせて集中と分散のバランス をとる 考え⽅
  36. 36 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ アーキテクチャを考える上 でのテクノロジーの扱い つねに”Why”を考える

    道具や”正しさ”に 振り回されてないようにする 考え⽅
  37. 37 ɹɹʛɹɹ© 2020 PLAID Inc. 2020.09.06ɹɹʛɹɹCNDT 2020ɹɹʛɹ まとめ ハイスケーラビリティを実現するには? -

    テクノロジーとクラウドを最⼤限に 活⽤すること - テクノロジーを⼿段として捉え、 組織 や⽂化を活かすこと - 変化させ続けること
  38. None