Edited at

Deis Workflow を Azure にデプロイするときには,vhd 用のストレージアカウントを流用してはいけない。

More than 1 year has passed since last update.

最近になって,Deis Workflow (以下,単に Workflow)を Azure にデプロイするための公式文書が出たようなので,その通りにやっていれば失敗しないはずなのだけれども。

自前でやりたい人,または自前でやった結果,イマイチなレスポンスになっている人のためのメモ。

タイトルは Workflow だけれども,Kubernetes (K8s) 一般でも成り立つかもしれない。

言いたいことは,タイトルで言い尽くしている。


Azure での K8s 一般論

K8s 一般論として,起動時/再起動時には,OS がマウントしている vhd は, OS の起動処理や K8s 関連のコンテナのアクセスが集中して,ストレージアカウントへのアクセスが急増する。

アクセスが集中すると,ストレージアカウントのグレードにも依るけれども,帯域制限(スロットリング)がかかる。


Azure での Workflow 一般論

Workflow のデフォルト設定では,registry は Workflow が提供するコンテナで,バックエンドストレージは,AzureBlob となっている。

Workflow では管理している Webアプリの情報を Postgres に保持するが,デフォルト設定では Workflow が提供するコンテナを用い,WAL-E を使ったバックアップ先は AzureBlob となる。

ここで,あんまり深いことを考えないで設定すると,既に存在するストレージアカウントに,これらののバックエンド Blob を置いてしまう。(大抵,既に存在するストレージには vhds がある。)

Workflow は,システム起動時に PaaS として管理していたコンテナの整合性を管理し,必要であれば registry コンテナの内容を再デプロイするよう K8s に対し指示を出す。


起動時に起こる高負荷


  • K8s の一般論として,起動時には pods 作成のため,ディスクへアクセスは多くなりがち。

  • Workflow の registry や postgres といった pods たちが,ストレージアカウントに対して,猛烈な勢いでアクセスを開始する。

同時に起こると,結果は考えるまでもない。ストレージへのアクセスは,スロットリングされ,下記のような事態に陥る。


  • いつまでたっても postgres のバックアップリカバリは完了しない。タイムアウト等で deis-postgres コンテナの再起動が繰り返される。

  • Workflow が管理しているアプリに対応する k8s の pods は, ContainerCreating のまま固まる。

コンテナ数 100 程度の規模でも復旧まで半日かかるような,長時間サービス停止に陥る。


なので

Workflow が使う AzureBlob のストレージアカウントは,vhds が入っているものとは分けましょう。

あと,Premium Disk の利用を検討しましょう。再起動時だけですが,効果が実感できます1

それなりにお金がかかりますけれども。





  1. もちろん起動後もアクセスは速いはずなのだけれども,体感できるとまでは言い難い。