Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

現場!実物!実践!マルチクラスタを運用するときの課題とコツ

687 vues

Publié le

2019年3月20日開催 『はてな×さくらが考えるテクノロジーの未来 〜コンテナ・分散型データセンター〜』のスライド資料です。

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

現場!実物!実践!マルチクラスタを運用するときの課題とコツ

  1. 1. さくらインターネット株式会社 Shuji Yamada (山田 修司) @uzyexeMar 20, 2019 現場!実物!実践! マルチクラスタを運用するときの課題とコツ
  2. 2. さくらインターネット技術本部 エンジニア 「さくらのクラウド」運用担当などののち、 現在はコンテナホスティング「Arukas」の開発に着手 (山田 修司) 2 SHUJI YAMADA
  3. 3. データセンター運用、サーバ運用、ネットワーク運用、 クラウド運用、コンテナ運用、Chef運用、Zabbix運 用、GitHub Enterprise運用、Slack運用・・・ 3 運用づくしの12年! (運用馬鹿)SHUJI YAMADA
  4. 4. 4 What is Arukas?
  5. 5. 6 登録ユーザー数
 20K+ コンテナ起動回数 (累計)
 210K+ 稼働イメージ数 (タグ別) 
 2K+ ユーザーの出身国 
 80カ国以上 Something for everyone
  6. 6. 7 コントロールパネル CONTROL PANEL
  7. 7. 現場!実物!実践!
  8. 8. ノード3 ノード4 ノード5 ノード1 ノード2 ノード3 ノード4 ノード5 ノード1 ノード2 Cluster Cluster 障害時には自動で収容変更 分散型高可用性クラスタの基本的動作 TYPICAL BEHAVIOR
  9. 9. API Server Scheduler Controller
 Manager KVS Master Worker Node 1 Pod 1 Docker Agentproxy Storage Monitoring Logging Registry Network Pod 2 Pod 3 Worker Node 2 Pod 4 Docker Agentproxy Pod 5 Pod 6 Cluster
  10. 10. 11 Worker Node Storage Master ‣ I/O性能(IOPS) ‣ inode数 ‣ 通信コネクション数 ‣ メモリ搭載量 ‣ コンテナ収容数 ‣ 通信コネクション数 ‣ 通信帯域 ‣ 通信帯域Networking ボトルネック BOTTLE NECK
  11. 11. 12 • トラフィックが溢れる • キューがどこかで詰まる • コンテナがクラックされる • 誰かがコインを掘りはじめる • KVSのデータが吹き飛ぶ • Docker が気絶する • コネクションが張れなくなる • NTP同期失敗してコントローラー気絶 • バージョンアップして壊れる • 再起動毎にマイグレーションの高負荷 • スパムメールを転送しはじめる • エージェントが突然気絶する コンテナあるある TYPICAL ERRORS
  12. 12. 13 •トラブルを引き起こす障害点が増える •学習コストが増加する •未知のエラーと遭遇しやすくなる •小さいほうが信頼性は高い コンポーネントが増えると・・・ PAIN
  13. 13. ブルーグリーンデプロイメント! サービスメッシュ! ローリングアップデート! Istio!Envoy! Spennier! IoT / Fog! Deep Leaning! HPC! CI/CD! Devが抱く理想 \ コンテナ管理プラットフォーム / カナリアリリース! オートスケール!
  14. 14. メトリクス管理! マルチクラウド対応! 仮想ネットワーク! ロードバランシング! マルチテナント対応! ログの統合管理! リニアスケール! 再起動したら直れ! Opsが抱く理想 \ データセンターOS / 自動構築! セキュリティ!
  15. 15. Container
  16. 16. Container DevOps REAL?
  17. 17. Docker KubernetesVPS ServerServer Load Balancer Load Balancer API
 Code API
 Code Bin/Libs Bin/Libs ServerServer Web
 Code Web
 Code Bin/Libs Bin/Libs Database API URL Web URL ServerServer ServerServer Load Balancer Load Balancer API
 Container API
 Container Bin/Libs Web
 Container Web
 Container Bin/Libs Bin/Libs Bin/Libs API URL Web URL Load Balancer Ingress Controller Node API Pod Web Pod Node API Pod Web Pod Database API URL Web URL Database
  18. 18. API URL Web URL CDN Secondary Primary LB Service B Service A Ingress
 Controller Cloud Vendor A DB DB LB LB Service B Service A Cloud Vendor B DB DB Cluster A Cluster B Cluster C
  19. 19. API URL Web URL CDN Secondary Primary LB Service B Service A Ingress
 Controller Cloud Vendor A DB DB LB LB Service B Service A Cloud Vendor B DB DB Cluster A Cluster B Cluster C
  20. 20. 21 •クラスタを活用すると・・・ ‣コンテナのワークロードは最適化できる •しかし、クラスタを自分達の手で管理すると・・・ ‣人的なワークロードが爆増 トレードオフ? TRADE-OFF?
  21. 21. 22 •クラスタを活用すると・・・ ‣コンテナのワークロードは最適化できる •しかし、クラスタを自分達の手で管理すると・・・ ‣人的なワークロードが爆増 •マネージドサービスを使うのが「ベストプラクティス」 トレードオフ? TRADE-OFF?
  22. 22. 23 •基本的には2個のクラスタがあればOK •プロダクションクラスタ •ステージングクラスタ •完全なクラスタ分離が必要なければ、名前空間で対処する •ワークロード単位 •チーム単位 クラスタをいくつ用意すべきか? HOW MANY CLUSTERS?
  23. 23. 24 •ベアメタルのほうが安価で高性能だが・・・ ‣クラウドなら、いつでも柔軟にノードを追加できる •既にノードがたくさんある場合・・・ ‣小さいノードを追加していく戦略がオススメ クラスタをスケールするならクラウド一択 SCALING
  24. 24. 25 •あまり物理的に距離が離れると・・・ ‣KVS間でのデータ同期に遅延が発生する ‣データ同期待ちでキューが貯まりやすくなる •同一データセンター内にまとめて収容するのがベスト ‣分散冗長よりも「データバックアップのほうが大切」 一つのクラスタを地理的に分散すべきか? RISKS
  25. 25. 26 サービス稼働中のArukasを東京に移設 石狩 Master Work Node ワークノード 東京 Master Work Node IP付け替えながら
 Masterを移設 シャットダウンしながら Work Nodeを移設 ちなみに、地理的に横断した事例・・・ CASE
  26. 26. 27 5台以上からは読取専用モードで追加 KVS 3台 KVS 5台 KVS 7台 同期モード:5台 読取専用モード:2台 同期モード:5台 読取専用モード:0台 同期モード:3台 読取専用モード:0台 (データ同期待ちによる遅延を抑制)
  27. 27. 28 •オートスケールの実行要件は日々変化していく •頻繁にスパイクするような負荷が発生しないなら・・・ ‣オートスケールは「無効」にすべき ‣ノードを手動で追加していく戦略のほうが最良 Work Node のオートスケール AUTO SCALING
  28. 28. 29 •リミット設定に到達したコンテナは揮発する ‣大きなリソースを使用するコンテナの再起動はコスト •一方、メモリリークが発生するとリソースを喰い尽くす ‣リミットは平常時リソースの100%強で設定すべき CPU と RAM を制約すべきか CPU / RAM LIMITATION
  29. 29. 30 •2つのコンテナが同一ファイルに同時に書き込もうとすると データ破損を引き起こす •回避するには・・・ ‣NFS や GlusterFS を使う(ロックをサポートしている) ‣独自の書き込みロック機構を実装する 共有ボリュームへの書き込み SHARED VOLUME
  30. 30. チーム文化
  31. 31. 33 1. ソフトウェア品質の問題 2. ヒューマンエラー ‣ 自動化の不足、人手不足、連携不足、手順書の不備 3. 顧客対応 ‣ 障害報告、説明対応、etc… 運用の生産性を低下させる要因 PRODUCTIVITY
  32. 32. 34 設計ポリシーがない 運用ガイドラインがない セキュリティポリシーがない 横展開するキーマンがいない 構築は簡単。運用は・・・ INDIVISUALIZATION 属人化フラグ
  33. 33. 35 1. 責任を明確に定義する 2. サービス維持に必要なアクセス権限の管理 3. ダメージを抑制するための仕組みづくり 4. 問題への対処と診断に必要なツールの導入 クラスタ管理者の役割 OWNER ROLE
  34. 34. Monitoring Alerts Emergency Response On-Call and Tickets Change Management Provisioning
  35. 35. 37 • Monitoring & Metrics ‣ Datadog • On-Call and Ticket ‣ PagerDuty • Exception / Error Tracking ‣ BugSnag • Automate Browser Testing ‣ Browser Stack 問題検出と問題解決 Operate
  36. 36. 38 利便性と複雑性は表裏一体 TRADE-OFF 自動化 抽象化 標準化 ブラックボックス化 見える化する仕組みがなければ隠 されやすい
  37. 37. 39 オペレーターからイネーブラーへ From Operators to Enablers
  38. 38. 40 運用できるインスタンス数
 10倍増 夜中のエスカレーション
 10倍減 ChefやZabbixに煩わされる時間 
 10倍減 Something for everyone
  39. 39. THANK YOU!

×