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

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 • 死活監視、ダッシュボード。 • レスポンスタイム、需要予測まで。

アラートと可用性• アラート件数：平均週５回 • 原因：システムの過負荷 • 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.”