Arukasの運用事例と、末永くインフラ運用していくためのTips(SRE Tech Talks...
-
date post
08-Feb-2017 -
Category
Technology
-
view
1.079 -
download
1
Transcript of Arukasの運用事例と、末永くインフラ運用していくためのTips(SRE Tech Talks...
Arukasにおける運用事例 末永くインフラ運用していくためのTips
さくらインターネット株式会社 Shuji Yamada (山田 修司)
@uzyexeJan30,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 + Marathon によるクラスタ化。
オンコール• PagerDuty を採用。
• 電話、SMS、メール通知機能を完備。
• 代表的な監視SaaSなどと連携可能。
変更管理(コードのデプロイ周り)
• 主に API / コントロールパネル など。 • CircleCI 経由、自動的に Chef が Deploy。 • Fail したときは、自動でデプロイ中断。 • 安全な Deploy が可能。 • Blue-Green や ゼロダウンタイムではない。
Users Ops
ContainerContainer
Operating System
Orchestrator/Container Scheduler
Infrastructure
Bins/Libs
App-1
APACHEZookeeper
Container
Arukasのインフラ構成
Bins/Libs
App-1
Bins/Libs
App-1
Docker
Docker Containers
Docker Support
Average Linux ServerRAM Usage
CoreOS RAM Usage161 MByte
Minimal OS
Data
A B
Data
A B
Automatic Update
• 省メモリ、省機能
• ディスクレス起動でも、RAM領域の消耗が少ない
• Cloud-Configとの組み合わせで高い冪等性を担保可能
CoreOS
• 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)
Terraform
Servers
cloud-config.ymlterraform apply
• Terraform for Sacloud + CoreOS + Cloud-Config
• 平均30分で数十台のサーバインスタンスを半自動で本番投入可能。
• 最も一般的なブート方法 • OSインストール作業が必要
• OSアップデート作業が必要
• +++
• OSバージョンを統一しやすい
• OSインストール作業不要
• 起動に失敗しやすい • +++
• サーバ単位でのOSバージョン管理
• OSインストール作業不要
• CD-ROMブート未対応のIaaSが多い
• +++
Network boot CD-ROM bootDisk boot
ServerBoot Options
• クラスタリソース管理フレームワーク。
• 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 9Host Servers Resource Pool
37
障害発生時の動作
しかし、ユーザーが多すぎる…
現実
予想
ギャップ
バラツキ
バラツキ
バラツキ
コンテナ数の推移
現実
予想
招待予約制を導入
コンテナ数の推移
現実
予想
招待予約制を導入
コンテナ数の推移
現実
招待予約制を導入
入場制限• 入力制御機構の一種。 • 安定的な品質を保つにはどこかに必要。 • 入力制御が無い=タスクは増え続ける。
Arukasの戦略• 頻繁な変更が必要なものだけ自前で管理。 • それ以外はSaaS等にアウトソーシング。
まとめ
• サイト信頼性エンジニアリング • ビジネスを守るために必要。
SRE WHY?
• タスクが増え続ける。 • 活用できない不要リソースが増える。 • 納期が守れなくなる。 • 顧客が逃げる。 • 会社が潰れる。
不安定なシステムが生み出す負債
• タスクは必要最小限になる。 • リソースが有効活用される。 • 納期を守れる。 • 顧客が増える。 • 利益が増える。
システムが安定化すると…
• 可用性における5番目の9は人間。 • ヒューマンエラーの原因 • コンテキストやメトリクスの不足。 • コミュニケーション上のトラブル。 • 誤情報、エラーの無視、エラーの軽視。
99.999%(5番目の9を探せ)
• エラーが自動復旧されるようになる。 • エラーの偽陽性率は高くなる。 • 手動対応できる職人の数は減少する。 • 効率と徹底のトレードオフ
システムが高度に複雑化するほど…
• 大惨事の予兆:軽微な故障、不具合 • 予兆は見逃されやすい。 • 認識不足、人間関係の問題など…。
• 正しい振り返りができる文化は大事。
故障と振り返り
“Hope is not a strategy.”