Cloud Foundry Advent Calendar 2017 - Qiita 20日目。

続き

前回の記事では、CF ならではのオペレーションの難しさについてお話をしました。それで書き終わればよかったのですが、泉のようにオペレーターのつらさは湧いてきます。

Disclaimer

この記事では CF の運用について、なんの解決策も提示しません。ただつらい思いを共有し、「あぁ、私も」と頷いてもらうことで、CF 運用のつらみと孤独感を和らげることを意図したものです。

ちなみに、著者は CF 好きです。

[System] Cloud Controller へのアクセス多すぎ問題

社内で CF を運用していると、簡単に API やフロントエンドの App が作れることから、やはり様々な自動化に CF の App を利用したいというご要望を頂きます。

すると、なにかしらの外部システムから cf push や cf scale, cf apps が実行されたりします。これらのリクエストの受け先は Cloud Controller であり、さらにその先には CCDB と呼ばれる org, space, app などの情報を保存している DB が存在します。

これは、Master/Replica 構成のため、スケールアウトができません。 (Master/slave - Wikipedia という単語は Politically Incorrect だそうですよ…)

そのため、利用者が増えるに従って徐々に CPU, Mem 使用率が上がっていき、気づいたら時すでに遅しになりかねません。

解決策のようなもの

まず、CC へのアクセスを分析するために、/var/vcap/sys/log/cloud_controller_ng 配下のアクセスログを解析しましょう。独自に作っているシステムからリクエストを投げている場合は、User Agent を設定すると、アクセスログが分かりやすいです。 CC は冗長化されているため、全体的な解析を行う際は Elastic Search や Splunk のようなログ解析が必要になるでしょう。

CCDB をスケールアップします。処理能力の高い VM を割り当てましょう。また、Replica の CCDB を Read Only な API として利用するようなアイデアも Creating a Read-Only Cloud Foundry API Server for Reporting 提案されていたりします。

[Log] Log 多すぎ問題

VM上での開発について考えると、これまで VM 上にログファイルを出力させて、何か問題が発生した場合は、/var/log 以下に出したファイルを確認していたことが多いと思います。

しかし、CF の場合は何十台もの VM 上で好き勝手にコンテナが作成され、各コンテナから出力された stdout や stderr をまとめて* どこかに出力する必要があります。そのためのエンドポイントは、 loggregator と呼ばれる CF のログシステムの中の traffic controller が提供してくれるのですが、VM が何十台もあり、数千のコンテナが動作している状態では、相当量のログが traffic controller から吐き出されることになります。

*コンテナから出力されたログを以降、 App Log と呼びます。

また、CF 自体に対するリクエストのほとんど受けている Gorouter のアクセスや、上記で述べた CC へのログも複数台の VM に対するアクセスを扱うだけに膨大な量となります*。

*これらの CF コンポーネントから出力されたログを System Log と呼びます。

App Log が多すぎる問題

これまで VM や実機での開発に慣れていると、ついログはローカルのストレージに溜め込むものと思われがちです。実際、利用者の中でコンテナのストレージにログを溜めたのだが、すぐにいっぱいになって困るという話を頂いたことがあります。

解決策のようなもの

ログがどれほど出力されているのかを CF 管理者だけでなく、利用者にもわかるようにし、利用者が全体から見てどれほどログのリソースを費やしているのか分かるようにする必要があります。

でなければ、VM と同じ感覚でストレージに溜めるがごとく、デバッグログを出力することとなります。擬似的でも良いので、お金に換算するといくらくらいになっているのかを利用者に伝えられるようにしておきましょう。

System Log が多すぎる問題

MicroService の CF は gRPC, http(s), wss などなど様々なプロトコルでコンポーネント間の通信を行い、その結果を /var/vcap/sys/log/<package名> の中で保存していることがほとんどです。

いざ障害が発生した時、もちろん Prometheus でメトリクスを追い、どの数値に異常があるか、top コマンドでリソースを費やしているプロセスについて調べたりしますが、何が原因だったかを追えるのは、アクセスログだったり、システムログだったりします。

しかし、System Log は基本的に固定サイズで log rotate されるようになっており、あとで追おうと思ったときには時すでに遅しとなっていることが多いです。

解決策のようなもの

App Log だけではなく、System Log も Elastic Search や Splunk にログを出しておくようなシステムを用意しましょう。

（各コンポーネントのログを外出しするためのシステムが、実は CF と同規模になりがちというのはここだけの話。子供がもう一人増えた気分です）

[Network] 結局スケールできない問題

CF は MicroService だから、独立したコンポーネントはいくらでもスケールできるんでしょ？

そう思っていた時期が私にもありました…

bosh deploy で VM数を変えようと思っても、実際問題、簡単にはスケールができなかったりします。（ちなみに Gorouter を 100以上増やそうとすると bosh が例外を出すという噂も…）

なぜか？

bosh を使っていると存在を忘れがちな IaaS の準備が間に合わないということがあるからです。具体的には、CF 用に切り分けたネットワークの IP が枯渇してしまったり、Hypervisor を物理的に購入しなければならなかったりすることが発生します。

AWS であっても実は最初に利用できる Instance 数に上限があったりします。 MicroService でコンポーネントを独立してるから、よっしゃスケールアウトしたろと思ったのに。現実は厳しい…

解決策のようなもの

キャパシティプランニングはもちろんのこと、利用者の数の増減を見越して予め IaaS 層の整備を考えておく必要があります。

今、稼働させている VM が全体でいくらか。IaaS がデフォルトで必要とするゲートウェイなども含めた上で、Shared IP はあとどれくらい残っているのか。

いつでも気付けるように、アラートとして登録すると良いでしょう。

[Security] セキュリティどう担保するの問題

コンピュータシステムの進展はすごいもので、数十年前は物理的に異なっていたシステムが、いまや同じ機器内に全く異なるアプリケーションが複数存在している状態となりました。

もちろん、金融分野のように非常にセンシティブな情報を扱う場合は、別の物理マシンだけデータを保存するというポリシーが取られるでしょうが、セキュリティと利便性はトレードオフの関係 であり、開発効率を高めるために CF に乗せ換えるという例も出てくることでしょう。

CF では App が同じ VM に同居しており（まあ、独立した VMでも同じ Hypervisorに乗っているわけですが）、セキュリティ担当者からしたら、全く異なるサービスが同じ VM に混在している状態にギョッとするわけです。

解決策のようなもの

正直、コンテナや VM という仕組みを利用している以上、解決策はあるのかと言いたいですが、Isolation Segments | Cloud Foundry Docs を利用するのは１つでしょう。

ただせっかくどのコンテナも仲良く一緒に管理してあげようという発想の CF で、Orgに応じて分割してしまうのは、運用コストなどを考えてあまり得策とは言えませんし、それを許したら全員が Isolation Segments を使いたい！となるでしょう。

CF オペレーターとしてできることは、cgroup や chroot によって実現されているコンテナの独立性をいかに守っていけるか。そのためには、

OS アップデートや buildpack のアップデートをこまめに行うこと
CF によって生じうるセキュリティのリスクとビジネスのリスクを対比して、それでも CF に乗せるかどうかの判断をお願いすること
CF のコンテナがなぜセキュリティ的な独立性を保てるのかを説明すること

が求められます。また１つ、学ばなければならないことが増えましたね…！

[Security] クレデンシャル多すぎるよ問題

直近で僕のチームで問題になっているのは、bosh が生成するクレデンシャルをいかに管理するのかです。

従来、各コンポーネントのセキュリティを守るためには、自分たちで証明書を自動生成するようにしなければならなかったところ、bosh のおかげで自動的に作られるのは良いことです。しかし、最初にデプロイした人の中でクレデンシャルが残されるようでは運用もままなりません。

しかも、複数の CF クラスタ運用となるとそのクレデンシャルの数は 100は超えると思います。

解決策のようなもの

この問題については、CF のコミュニティも温度感が高いのか、CredHub | Cloud Foundry Docs と呼ばれるクレデンシャル管理用のコンポーネントが開発されています。

Credhub は監査ログも

しかし、新しいコンポーネントがまた増えて、アラート対象も増えるということですね！（白目

まとめ

前回の記事よりもより具体的な問題について、この記事ではまとめました。細かい話まで含めるとオペレーターのつらさは、もっとあります。（よかったらコメントでシェアしてください）

CF オペレーターの皆様には、真っ赤なアラートではなく、真っ赤な服の人が来ることを祈って。でも、クリスマス商戦も迫ってくる…!

開発効率を上げるため、CF オペレーターは今日も働く

To be continued…