Cloud Foundry Advent Calendar 2017 - Qiita 18日目。
はじめに
僕は普段、業務で Cloud Foundry (CF) の運用を行っております。 bosh でデプロイされる CF は、auto resurrection のおかげもあり、めっちゃ運用が楽ちん、週末も清々しく過ごせる。オペレーターもようやく長きにわたるシステム管理の戦いから解放…
なんてことはなく、大変なことがたくさんあります。
その痛みについて、ここで共有しようと思います。
Disclaimer
この記事では CF の運用について、なんの解決策も提示しません。ただ CF 運用で大変だった思いを共有し、「あぁ、私も」と頷いてもらうことで、CF 運用のつらみと孤独感を和らげることを意図したものです。
ちなみに、著者は CF 好きです。
[System] Noisy Neighbor 問題
CF の利用者からしたメリットは、システム運用についてほとんど気にせずに App を動作させられることです。というか、コンテナに起因する性能面のデメリット以外は、利用者にとってはメリットばかりでしょう。
なぜなら、その分の運用負担はオペレーターに回っているからです
さて、CF では利用者にシステムについて意識させないことで、発生する問題があります。それは、Noisy Neighbor問題です。
CF では diego cell と呼ばれるコンテナ実行環境の VMに、たくさんの App が動いています。すると、同居している App の 1つがたくさんのリソース（CPU, MEM）を使うと、他の App も影響を受けてしまいます。
もちろん、App の push 時に定義する manifest.yml にて、リソース使用量の上限を定義するのですが、突発的に CPU を使ったりすると、VM 全体に負荷がかかってしまい、あえなく monit が VM を再起動… なんてことが起きてしまいます。
Pivotal Web Service や Heroku のように、利用料を取っていれば、利用者側もリソースの使いすぎを意識するのですが、社内システムとして運用している立場上、社内の利用者からお金をもらうということは難しく、リソース使用量の非常に多い App については、色々と悩まされることがあります。
解決策的なもの
CF の利用者は良い意味でインフラについて考える必要があまりなくなります。その半面、リソースを酷使してもそれについて気づきにくくもあります。 社内システムであろうが、リソース使用量に対して仮想的な料金を提示して、CF全体のリソースに対する意識を高めましょう
[System] コンポーネント多すぎ問題
CF は MicroService を設計思想として、コンポーネントごとに機能を独立させているがゆえに、メリデメがあります（街みたいなシステムです）
大きなメリットはやはり、各コンポーネントごとにスケールアウトができたり、各コンポーネントがクラッシュしてもシステム全体への影響を減らせることでしょう。そのかわり、デメリットもあります。
アップデートするもの多すぎ問題
CF はアプリケーションレイヤーまで担当するため、bosh をはじめとするインフラレイヤーから、blobstore のようなストレージ、loggregator のログシステム、garden によるコンテナ実行環境などなど様々なコンポーネントによって構築されています。
そのため、バージョンアップをする際もコンポーネントを1つずつアップデートしていく必要があります。とはいえ、そこは bosh の release という仕組みがうまく解決しており、各コンポーネントに対して、よしなにバージョンアップを行ってくれます（バージョンアップに失敗することもそこそこありますが…）
ただ、そのたびに各コンポーネントの中身がかわり、あるコンポーネントが急にメモリを消費するようになったり、処理速度が下がったりするなどトラブルも生じがちです。
ありがたいことではあるのですが、CF は随時新しい仕組みが取り入れられていくため、アップデートの戦略は利用のされ方に応じて考えていく必要があります。
とはいえ、バージョンアップにまつわる難しさは、Monolith アーキテクチャでも同じなので、一概に CF が悪いというわけではありません
アップデートするとアラートも変わるよ問題
我々オペレーターは、日々、アラートの研鑽につとめます。本当に重要なアラートだけ通知するようにしなければ、深夜に不要なアラートで目が覚めるなど、QoL に関わります。
しかし、コンポーネントをアップデートするとその閾値や項目を変更する必要があり、なかなか適切な値に設定するのが難しいです。コンポーネントの名前も変わったり、メモリをとても使うように実装が変わっていたり、変更すべき箇所が多数に渡ります。
解決策のようなもの
アラートに関して言えば、**そもそもアラートってなんのためにあるんだっけ？**ということに立ち返ると、「ユーザへの影響が発生している（そうな）場合に、アクションを取る」ためにあります。なんだかわからないけどまずそう、という程度ものは後で時間をとって調べれば良いのですから（まあ、そういって調べずに終わりますが）。
CF の場合も本番環境へ App をリリースしておき、Appの動作に異常はないか（性能劣化、push できないなど）さえ確認 できていれば一安心なので、まずはここを抑えましょう。
例えば、 pivotal-cf/downtimer のような App をデプロイして監視対象としておきましょう。
オペレーターの学習コストが高すぎるよ問題
CF の全コンポーネントを隅から隅まで把握している人はこの世に何人いるのでしょうか？ 少なくとも僕は CFに 1年以上携わっていますが、アップデートの件もあり、すべてのシステムの詳細を把握できているとは正直言い難いです。
しかし、障害はオペレーターの学習時間など待ってはくれません。インフラからアプリケーションまでカバーする CF は、問題発生時の理由も上から下まで存在します。
そんななかでオペレーターには、CF 全体のある程度の知識と各コンポーネントやレイヤー（ネットワーク、OS、ランタイム、ストレージ）に対する深い理解が求められます。
正直、数人規模でオペレーションを回すのは、スーパーハカー集団でもない限りは無謀だと思っています
まとめ
記事が長くなりそうなので、今日はここまで。まとめますと、
- CF は利用者が共用するシステムのため、利用者（つまり他人）の使い方まで目を配る必要がある
- CF は Micro Service というアーキテクチャであり、さらにインフラからアプリケーションまで面倒を見るシステムのため、オペレーションに様々な困難を生じる
おっと、電話がかかってきたぞ。