最近になって，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。
それなりにお金がかかりますけれども。
-
もちろん起動後もアクセスは速いはずなのだけれども，体感できるとまでは言い難い。 ↩