Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Arukasにおける運用事例
末永くインフラ運用していくためのTips
さくらインターネット株式会社
Shuji Yamada (山田 修司)
@uzyexeJan	30,	2017
SRE Tech Talks #2
SHUJI YAMADA
• さくらインターネット 10年目
• データセンター運用スタッフ
• バックボーンネットワーク運用
• さくらのクラウド運用
• Docker ホスティング Arukas 担当 <- 今ココ
(山田 修司)
What’s
Arukas?
Run
Dockerized Applications
100,000+
Dockerized Applications
40000
Containers
35000
Users
27
Docker Clusters
アジェンダ
• ビジネスと信頼性の関係について (5分)
• Arukasの運用の中身 (5分)
• まとめ (5分)
Reliability
Open 24/7
利益
信頼関係
両立できなければ失敗している。
Users Maintainers
Users Maintainers
15
バラツキ
?
?
Users Maintainers
Users Maintainers
大なり小なり立ちはだかる問題
• インフラの構築、整備が間に合わない。
• リソース不足、人手不足、資金不足。
• 潜在的欠陥が顕在化。
• 技術的負債が増加。
“Hope is not a strategy.”
Monitoring Alerts
Emergency Response On-Call and Tickets
Change Management Provisioning
監視
• Datadog + NewRelic
• 死活監視、ダッシュボード。
• レスポンスタイム、需要予測まで。
アラートと可用性
• アラート件数:平均週5回
• 原因:システムの過負荷
• CPU、メモリ、帯域、コネクション数、etc…
障害対応
1. 設定ミスを自動検知して自動対応。
• サーバ起動時にServerSpecを自動実行。
2. 予兆を自動検知して自動対応。
• 自前の監視スクリプトを定期実行。
3. ハードウェア障害を自動検知して自動対応。
• Mesos + ...
オンコール
• PagerDuty を採用。
• 電話、SMS、メール通知機能を完備。
• 代表的な監視SaaSなどと連携可能。
変更管理(コードのデプロイ周り)
• 主に API / コントロールパネル など。
• CircleCI 経由、自動的に Chef が Deploy。
• Fail したときは、自動でデプロイ中断。
• 安全な Deploy が可能。
• Bl...
Users Ops
ContainerContainer
Operating System
Orchestrator/Container Scheduler
Infrastructure
Bins/Libs
App-1
APACHE
Zookeeper
Conta...
Docker
Docker
Containers
Docker Support
Average Linux Server

RAM Usage
CoreOS RAM Usage
161 MByte
Minimal OS
Data
A B
Dat...
• CoreOS 版 Cloud-Init
• 様々なConfigを一つのymlファイルに。
• 1役割(Role)あたり 1cloud-config 化が可能。
• Chef や Ansible より学習コストが低い。
Cloud-Config
c...
Terraform
Servers
cloud-config.yml
terraform apply
• Terraform for Sacloud + CoreOS + Cloud-Config
• 平均30分で数十台のサーバインスタンスを半自動...
• 最も一般的なブート方法
• OSインストール作業が必要
• OSアップデート作業が必要
• +++
• OSバージョンを統一しやすい
• OSインストール作業不要
• 起動に失敗しやすい
• +++
• サーバ単位でのOSバージョン管理
•...
• クラスタリソース管理フレームワーク。
• Apache のトップレベルプロジェクトの一つ。
• Twitter、Airbnb、NETFLIX で採用。
• コンテナの実行をサポート。
Mesos
一つの巨大な仮想リソースへ
Marathon
• Mesos Frameworks の一つ。
• サーバとアプリの状態を自動検知。
• 自動復旧までサポート。
• Task (Application) の常時稼働を保証。
36
コンテナ資源の配置制御
FREE
1 2 3
4 5 6
7 8 9
Mesos+Marathon を利用した
Host Servers Resource Pool
FREE
1 2 3
4 5 6
7 8 9
Host Servers Resource Pool
37
障害発生時の動作
しかし、ユーザーが多すぎる…
現実
予想
ギャップ
バラツキ
バラツキ
バラツキ
コンテナ数の推移
現実
予想
招待予約制を導入
コンテナ数の推移
現実
予想
招待予約制を導入
コンテナ数の推移
招待予約制を導入
入場制限
• 入力制御機構の一種。
• 安定的な品質を保つにはどこかに必要。
• 入力制御が無い=タスクは増え続ける。
Arukasの戦略
• 頻繁な変更が必要なものだけ自前で管理。
• それ以外はSaaS等にアウトソーシング。
まとめ
• サイト信頼性エンジニアリング
• ビジネスを守るために必要。
SRE WHY?
• タスクが増え続ける。
• 活用できない不要リソースが増える。
• 納期が守れなくなる。
• 顧客が逃げる。
• 会社が潰れる。
不安定なシステムが生み出す負債
• タスクは必要最小限になる。
• リソースが有効活用される。
• 納期を守れる。
• 顧客が増える。
• 利益が増える。
システムが安定化すると…
• 可用性における5番目の9は人間。
• ヒューマンエラーの原因
• コンテキストやメトリクスの不足。
• コミュニケーション上のトラブル。
• 誤情報、エラーの無視、エラーの軽視。
99.999%(5番目の9を探せ)
• エラーが自動復旧されるようになる。
• エラーの偽陽性率は高くなる。
• 手動対応できる職人の数は減少する。
• 効率と徹底のトレードオフ
システムが高度に複雑化するほど…
• 大惨事の予兆:軽微な故障、不具合
• 予兆は見逃されやすい。
• 認識不足、人間関係の問題など…。
• 正しい振り返りができる文化は大事。
故障と振り返り
“Hope is not a strategy.”
Arukasの運用事例と、末永くインフラ運用していくためのTips(SRE Tech Talks #2)
Arukasの運用事例と、末永くインフラ運用していくためのTips(SRE Tech Talks #2)
Upcoming SlideShare
Loading in …5
×

Arukasの運用事例と、末永くインフラ運用していくためのTips(SRE Tech Talks #2)

4,140 views

Published on

2017年1月30日に開催された「SRE Tech Talks #2」において、技術本部 山田 修司が「Arukasの運用事例と、末永くインフラ運用していくためのTips」と題し、講演した際の資料です。

Published in: Technology

Arukasの運用事例と、末永くインフラ運用していくためのTips(SRE Tech Talks #2)

  1. 1. Arukasにおける運用事例 末永くインフラ運用していくためのTips さくらインターネット株式会社 Shuji Yamada (山田 修司) @uzyexeJan 30, 2017 SRE Tech Talks #2
  2. 2. SHUJI YAMADA • さくらインターネット 10年目 • データセンター運用スタッフ • バックボーンネットワーク運用 • さくらのクラウド運用 • Docker ホスティング Arukas 担当 <- 今ココ (山田 修司)
  3. 3. What’s Arukas?
  4. 4. Run Dockerized Applications 100,000+ Dockerized Applications
  5. 5. 40000 Containers 35000 Users 27 Docker Clusters
  6. 6. アジェンダ • ビジネスと信頼性の関係について (5分) • Arukasの運用の中身 (5分) • まとめ (5分)
  7. 7. Reliability
  8. 8. Open 24/7
  9. 9. 利益
  10. 10. 信頼関係
  11. 11. 両立できなければ失敗している。
  12. 12. Users Maintainers
  13. 13. Users Maintainers
  14. 14. 15
  15. 15. バラツキ ? ?
  16. 16. Users Maintainers
  17. 17. Users Maintainers 大なり小なり立ちはだかる問題 • インフラの構築、整備が間に合わない。 • リソース不足、人手不足、資金不足。 • 潜在的欠陥が顕在化。 • 技術的負債が増加。
  18. 18. “Hope is not a strategy.”
  19. 19. Monitoring Alerts Emergency Response On-Call and Tickets Change Management Provisioning
  20. 20. 監視 • Datadog + NewRelic • 死活監視、ダッシュボード。 • レスポンスタイム、需要予測まで。
  21. 21. アラートと可用性 • アラート件数:平均週5回 • 原因:システムの過負荷 • CPU、メモリ、帯域、コネクション数、etc…
  22. 22. 障害対応 1. 設定ミスを自動検知して自動対応。 • サーバ起動時にServerSpecを自動実行。 2. 予兆を自動検知して自動対応。 • 自前の監視スクリプトを定期実行。 3. ハードウェア障害を自動検知して自動対応。 • Mesos + Marathon によるクラスタ化。
  23. 23. オンコール • PagerDuty を採用。 • 電話、SMS、メール通知機能を完備。 • 代表的な監視SaaSなどと連携可能。
  24. 24. 変更管理(コードのデプロイ周り) • 主に API / コントロールパネル など。 • CircleCI 経由、自動的に Chef が Deploy。 • Fail したときは、自動でデプロイ中断。 • 安全な Deploy が可能。 • Blue-Green や ゼロダウンタイムではない。
  25. 25. Users Ops
  26. 26. ContainerContainer Operating System Orchestrator/Container Scheduler Infrastructure Bins/Libs App-1 APACHE Zookeeper Container Arukasのインフラ構成 Bins/Libs App-1 Bins/Libs App-1
  27. 27. Docker Docker Containers Docker Support Average Linux Server
 RAM Usage CoreOS RAM Usage 161 MByte Minimal OS Data A B Data A B Automatic Update • 省メモリ、省機能 • ディスクレス起動でも、RAM領域の消耗が少ない • Cloud-Configとの組み合わせで高い冪等性を担保可能 CoreOS
  28. 28. • CoreOS 版 Cloud-Init • 様々なConfigを一つのymlファイルに。 • 1役割(Role)あたり 1cloud-config 化が可能。 • Chef や Ansible より学習コストが低い。 Cloud-Config cloud-config.yml (Template Config) Instance hostname passwd users groups file directory run-cmd unit (systemd)
  29. 29. Terraform Servers cloud-config.yml terraform apply • Terraform for Sacloud + CoreOS + Cloud-Config • 平均30分で数十台のサーバインスタンスを半自動で本番投入可能。
  30. 30. • 最も一般的なブート方法 • OSインストール作業が必要 • OSアップデート作業が必要 • +++ • OSバージョンを統一しやすい • OSインストール作業不要 • 起動に失敗しやすい • +++ • サーバ単位でのOSバージョン管理 • OSインストール作業不要 • CD-ROMブート未対応のIaaSが多い • +++ Network boot CD-ROM bootDisk boot Server Boot Options
  31. 31. • クラスタリソース管理フレームワーク。 • Apache のトップレベルプロジェクトの一つ。 • Twitter、Airbnb、NETFLIX で採用。 • コンテナの実行をサポート。 Mesos
  32. 32. 一つの巨大な仮想リソースへ
  33. 33. Marathon • Mesos Frameworks の一つ。 • サーバとアプリの状態を自動検知。 • 自動復旧までサポート。 • Task (Application) の常時稼働を保証。
  34. 34. 36 コンテナ資源の配置制御 FREE 1 2 3 4 5 6 7 8 9 Mesos+Marathon を利用した Host Servers Resource Pool
  35. 35. FREE 1 2 3 4 5 6 7 8 9 Host Servers Resource Pool 37 障害発生時の動作
  36. 36. しかし、ユーザーが多すぎる…
  37. 37. 現実 予想 ギャップ バラツキ バラツキ バラツキ コンテナ数の推移
  38. 38. 現実 予想 招待予約制を導入 コンテナ数の推移
  39. 39. 現実 予想 招待予約制を導入 コンテナ数の推移
  40. 40. 招待予約制を導入
  41. 41. 入場制限 • 入力制御機構の一種。 • 安定的な品質を保つにはどこかに必要。 • 入力制御が無い=タスクは増え続ける。
  42. 42. Arukasの戦略 • 頻繁な変更が必要なものだけ自前で管理。 • それ以外はSaaS等にアウトソーシング。
  43. 43. まとめ
  44. 44. • サイト信頼性エンジニアリング • ビジネスを守るために必要。 SRE WHY?
  45. 45. • タスクが増え続ける。 • 活用できない不要リソースが増える。 • 納期が守れなくなる。 • 顧客が逃げる。 • 会社が潰れる。 不安定なシステムが生み出す負債
  46. 46. • タスクは必要最小限になる。 • リソースが有効活用される。 • 納期を守れる。 • 顧客が増える。 • 利益が増える。 システムが安定化すると…
  47. 47. • 可用性における5番目の9は人間。 • ヒューマンエラーの原因 • コンテキストやメトリクスの不足。 • コミュニケーション上のトラブル。 • 誤情報、エラーの無視、エラーの軽視。 99.999%(5番目の9を探せ)
  48. 48. • エラーが自動復旧されるようになる。 • エラーの偽陽性率は高くなる。 • 手動対応できる職人の数は減少する。 • 効率と徹底のトレードオフ システムが高度に複雑化するほど…
  49. 49. • 大惨事の予兆:軽微な故障、不具合 • 予兆は見逃されやすい。 • 認識不足、人間関係の問題など…。 • 正しい振り返りができる文化は大事。 故障と振り返り
  50. 50. “Hope is not a strategy.”

×