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

1. Arukasにおける運用事例
末永くインフラ運用していくためのTips
さくらインターネット株式会社
Shuji Yamada (山田 修司)
@uzyexeJan 30, 2017
SRE Tech Talks #2

2. SHUJI YAMADA
• さくらインターネット 10年目
• データセンター運用スタッフ
• バックボーンネットワーク運用
• さくらのクラウド運用
• Docker ホスティング Arukas 担当 <- 今ココ
（山田 修司）

3. What’s
Arukas?

5. Run
Dockerized Applications
100,000+
Dockerized Applications

6. 40000
Containers
35000
Users
27
Docker Clusters

7. アジェンダ
• ビジネスと信頼性の関係について (5分)
• Arukasの運用の中身 (5分)
• まとめ (5分)

8. Reliability

9. Open 24/7

10. 利益

11. 信頼関係

12. 両立できなければ失敗している。

13. Users Maintainers

14. Users Maintainers

15. 15

16. バラツキ
?
?

17. Users Maintainers

18. Users Maintainers
大なり小なり立ちはだかる問題
• インフラの構築、整備が間に合わない。
• リソース不足、人手不足、資金不足。
• 潜在的欠陥が顕在化。
• 技術的負債が増加。

19. “Hope is not a strategy.”

20. Monitoring Alerts
Emergency Response On-Call and Tickets
Change Management Provisioning

21. 監視
• Datadog + NewRelic
• 死活監視、ダッシュボード。
• レスポンスタイム、需要予測まで。

23. アラートと可用性
• アラート件数：平均週５回
• 原因：システムの過負荷
• CPU、メモリ、帯域、コネクション数、etc…

24. 障害対応
1. 設定ミスを自動検知して自動対応。
• サーバ起動時にServerSpecを自動実行。
2. 予兆を自動検知して自動対応。
• 自前の監視スクリプトを定期実行。
3. ハードウェア障害を自動検知して自動対応。
• Mesos + Marathon によるクラスタ化。

25. オンコール
• PagerDuty を採用。
• 電話、SMS、メール通知機能を完備。
• 代表的な監視SaaSなどと連携可能。

26. 変更管理（コードのデプロイ周り）
• 主に API / コントロールパネル など。
• CircleCI 経由、自動的に Chef が Deploy。
• Fail したときは、自動でデプロイ中断。
• 安全な Deploy が可能。
• Blue-Green や ゼロダウンタイムではない。

27. Users Ops

28. ContainerContainer
Operating System
Orchestrator/Container Scheduler
Infrastructure
Bins/Libs
App-1
APACHE
Zookeeper
Container
Arukasのインフラ構成
Bins/Libs
App-1
Bins/Libs
App-1

29. 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

30. • 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)

31. Terraform
Servers
cloud-config.yml
terraform apply
• Terraform for Sacloud + CoreOS + Cloud-Config
• 平均30分で数十台のサーバインスタンスを半自動で本番投入可能。

32. • 最も一般的なブート方法
• OSインストール作業が必要
• OSアップデート作業が必要
• +++
• OSバージョンを統一しやすい
• OSインストール作業不要
• 起動に失敗しやすい
• +++
• サーバ単位でのOSバージョン管理
• OSインストール作業不要
• CD-ROMブート未対応のIaaSが多い
• +++
Network boot CD-ROM bootDisk boot
Server
Boot Options

33. • クラスタリソース管理フレームワーク。
• Apache のトップレベルプロジェクトの一つ。
• Twitter、Airbnb、NETFLIX で採用。
• コンテナの実行をサポート。
Mesos

34. 一つの巨大な仮想リソースへ

35. Marathon
• Mesos Frameworks の一つ。
• サーバとアプリの状態を自動検知。
• 自動復旧までサポート。
• Task (Application) の常時稼働を保証。

36. 36
コンテナ資源の配置制御
FREE
1 2 3
4 5 6
7 8 9
Mesos+Marathon を利用した
Host Servers Resource Pool

37. FREE
1 2 3
4 5 6
7 8 9
Host Servers Resource Pool
37
障害発生時の動作

38. しかし、ユーザーが多すぎる…

39. 現実
予想
ギャップ
バラツキ
バラツキ
バラツキ
コンテナ数の推移

40. 現実
予想
招待予約制を導入
コンテナ数の推移

41. 現実
予想
招待予約制を導入
コンテナ数の推移

42. 招待予約制を導入

43. 入場制限
• 入力制御機構の一種。
• 安定的な品質を保つにはどこかに必要。
• 入力制御が無い＝タスクは増え続ける。

44. Arukasの戦略
• 頻繁な変更が必要なものだけ自前で管理。
• それ以外はSaaS等にアウトソーシング。

45. まとめ

46. • サイト信頼性エンジニアリング
• ビジネスを守るために必要。
SRE WHY?

47. • タスクが増え続ける。
• 活用できない不要リソースが増える。
• 納期が守れなくなる。
• 顧客が逃げる。
• 会社が潰れる。
不安定なシステムが生み出す負債

48. • タスクは必要最小限になる。
• リソースが有効活用される。
• 納期を守れる。
• 顧客が増える。
• 利益が増える。
システムが安定化すると…

49. • 可用性における5番目の9は人間。
• ヒューマンエラーの原因
• コンテキストやメトリクスの不足。
• コミュニケーション上のトラブル。
• 誤情報、エラーの無視、エラーの軽視。
99.999%（5番目の9を探せ）

50. • エラーが自動復旧されるようになる。
• エラーの偽陽性率は高くなる。
• 手動対応できる職人の数は減少する。
• 効率と徹底のトレードオフ
システムが高度に複雑化するほど…

51. • 大惨事の予兆：軽微な故障、不具合
• 予兆は見逃されやすい。
• 認識不足、人間関係の問題など…。
• 正しい振り返りができる文化は大事。
故障と振り返り

52. “Hope is not a strategy.”