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

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

3.
What’s
Arukas?

4.
Run
Dockerized Applications
100,000+
Dockerized Applications

5.
40000
Containers
35000
Users
27
Docker Clusters

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

7.
Reliability

8.
Open 24/7

9.
利益

10.
信頼関係

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

12.
Users Maintainers

13.
Users Maintainers

14.
15

15.
バラツキ
?
?

16.
Users Maintainers

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

18.
“Hope is not a strategy.”

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

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

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

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

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

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

25.
Users Ops

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

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

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

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

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

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

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

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

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

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

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

40.
招待予約制を導入

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

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

43.
まとめ

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

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

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

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

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

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

50.
“Hope is not a strategy.”