Open Infrastructure Summit上海、LINEに聞いた大規模なOpenStackクラスター運用のポイントとは？

クラウドネイティブの世界ではハードウェアは壊れるモノ、ソフトウェアにはバグがあるという発想でシステム運用に望むことが、成功へのステップであると言っても過言ではない。CI/CDの領域でさまざまなデプロイメント方法が実践されているのも、失敗しても元に戻せることを前提にしているからだし、プライベートクラウドとパブリッククラウドを併用するのもマクロ的に見ればトラブルからのリカバリー手段を用意しているとも言えるだろう。

そのような考えを反映したのか、昨今の多くのカンファレンスにおいて、「失敗からこうやって立ち上がった」という経験を共有する内容のセッションが評価されている。今回のOpen Infrastructure Summitでも、LINEによる大規模なOpenStack環境におけるメッセージキューイング関連のトラブルに関する詳細なセッションが行われた。セッションの会場となった会議室は、立ち見の参加者が出るほどの盛況だったという。セッションの内容は以下のページを参照されたい。

How we used RabbitMQ in wrong way at a scale

このセッションを担当したLINEのエンジニア3名に、現地でインタビューを行った。参加したのは、西脇雄基氏（Engineering Manager）、Dinesh Bhor氏（Infrastructure Software Engineer）、室井雅仁氏（Senior infrastructure Software Engineer）の3名だ。

LINEのインフラストラクチャーチーム。左からBhor氏、西脇氏、室井氏

ブレークアウトセッション、お疲れ様でした。スケジュールが合わなくて参加できませんでしたが、反響はどうでしたか？

西脇：大変良い感じでしたね。部屋も満員になって後ろのほうには立ち見の人もいましたし。LINEはOpenStackのユーザーとしてはまだ経験が浅く、運用開始は2016年ぐらいからですが、その時に遭遇したトラブルへの対処を共有するという内容でした。私自身は2年前にLINEに入ってOpenStackに関わっていますが、今はインフラストラクチャーのエンジニアリングチームのマネージャーとして、OpenStackのクラウドだけではなくKubernetesのAs a Service、サーバーレスのインフラストラクチャーの3つのチームのマネージャーとして働いています。

3つのプロジェクトを統括するというのは大変だと思いますが、As a Serviceを運用する目的は？

西脇：インフラストラクチャーチームとしては、システム全体の活用度合いをもっと上げたいという思いがありますが、実際には仮想マシン上で何が行われているのかはそのアプリケーション担当チームでないとわかりません。しかしこれまでの調査では、CPU稼働率が10％に満たないサーバーが全体の約60％もあることが分かっています。つまり、それくらいシステムのリソースを上手く使いこなせていないわけです。だから運用チームとしては、もっと集約するなり最適化を行いたいと。そしてそれを実行するためには、ソフトウェアの部分とインフラストラクチャーの部分を分離して、アプリケーションの部分からは抽象化されたリソースだけを見せて、インフラストラクチャー側でリソースを最適化するという方法を取ろうと思っています。

それを実現するために、KubernetesやFunction as a Serviceのようなマネージドなサービスを提供するシステムの運用を拡げていって、運用チームがアプリケーションチームにお願いしなくても最適化が可能なシステムに向かって行きたいと思っています。そのためのAs a Serviceのほうに行こうというのが、我々のチームの方向性です。でもいきなり明日から「Kubernetesにしてください」と言っても難しいので、徐々にやろうとしているという感じです。

室井さんはNTTの頃に何度かお話を聞いたことがありますが、LINEでは初めてですね。

室井：そうですね。私は今年（2019年）8月の初めにLINEに転職したので、まだLINEでは新人という感じです。基本的にはLINEのプライベートクラウドのバックボーンの部分を担当しています。LINEではIaaS以外にもオブジェクトストレージやメッセージングなどもas a Serviceとして提供していますが、その部分にも関わっている感じですね。

そしてDineshさんは？

Bhor：私はLINEの社内向けのプライベートクラウド、Verdaのプラットフォームエンジニアです。今回は西脇さんと一緒にセッションでのプレゼンテーションを担当しました。

LINEはインターナショナルな会社だと思いますが、インフラストラクチャーチームの編成はどんな感じですか？

西脇：実は日本人のエンジニアは少数派なんですね。他にはインド、中国、フランス、ロシア、いろいろな国からエンジニアがやってきています。

Bhor：今だとインドと中国のエンジニアが同じ数かな。

西脇さんはセッションでの講演だけではなく、Large-Scale SIGというディスカッションがメインのセッションにも参加されていました。私もそのセッションに参加して議論を見ていましたが、OpenStackを大規模なスケールで導入した際に起こるトラブルなどにどうやって対処していくのか？　という議題に対して、余りまとまらなかったなぁという印象です。それについては？

西脇：我々のセッションでは、大規模なクラスターを運用する時に発生するRabbitMQのトラブルに関しての発表をしました。実際にそのトラブルに対応してみると、OpenStackの内部でどんな処理が行われているのか、RPCのコールはどこで何回発生しているのか、というようなことはどこにも書かれていないというか、分からないんですよね。だから大規模にやっていくと、問題が起こったらその場その場で対応するということにならざるを得ない。それに改善するためにどうしたら良いのかをLarge-Scale SIGのほうでも議論はされていくことになると思いますが。

実際の議論の中では、大規模なクラスター運用のためにはまずドキュメンテーションを進めるべきだという意見と、それよりも内部の処理を可視化するためのメトリクス、Observabilityを優先してやるべきだという2つの意見が出ました。それについては？

Bhor：実際にはどっちを選択するというのではなく両方やるべきだと思いますけど（笑）

そうですよね。でもOpenStackではドキュメンテーションは常に後回しで昔から弱点として挙げられていました。

室井：ただ大規模になればなるほど、個々の処理が何をやっているのかを積み上げないと理解できないと思うので、Observabilityは重要だと思います。LINEでも、その部分に関しては何か貢献できたらと思っています。

KubernetesのようにPodの中にサイドカーで観測するためのモジュールをインジェクトできればやりやすくなるのでは思いますが。

室井：それはきっとデータプレーンの部分でのObservabilityだと思います。私が注目しているのはコントロールプレーンのほう、つまり制御を行うモジュールが何をやっているのか？　という部分なのです。なので可視化という意味では、ちょっとタイプが違うと思います。

可視化という部分ではOpenStackにはCeilometerというコンポーネントがあり、テレメトリー情報を収集することになっていますが、あまり活発に開発が進んでいるという印象はありません。CERNも途中でCeilometerの利用を止めていたという記憶があります。

室井：そうですね。しかしモジュールが利用するRPCの詳細などが分からないとどこで何が起こっているのか把握できないと思いますので、可視化は重要だと思います。最終的にソースを読むしかないというのはちょっと（苦笑）。

西脇：個人的な意見ですが、OpenStackに欠けている部分として「詳細な数値を取る」そして「それをもとにエミュレーションする」といった部分が欠けていると思っています。

とりあえず動けば良いみたいな？

西脇：そうですね。それを元に議論していかないといけないのに、そもそも元になるデータがないという。

室井：実際に例えば仮想マシンを立ち上げる際に、RPCが何回コールされるのか、キューには何が入るのか、そういう細かな仕様を説明できる人が世界にはいないんじゃないかなと思います。そこで、まずはそれについて詳細なデータを取れる仕組みを作りたいと。

西脇：ユーザーサイドだけではなく、もっと大規模にクラウドサービスを展開しているベンダー側の協力がないと、Large-Scale SIGも上手くいかないんじゃないかなと思います。

そうですよね、大規模にOpenStackを使っているOVHとかRackspaceが環境や知見を出し合わないと、実際のところ100台のクラスターで上手くいっても数千台のレベルになったら何が起こるのかわからないというのでは危険ですよね。最近、カオスエンジニアリングというのが注目されていますが、OpenStackでもそういう動きはあるんですか？

室井：OpenStackにはErisというプロジェクトがあります。これはテストの一環として進められているものですが、その中で故障に対応するためのテストのような感じで耐障害性については開発が進んでいます。ただまだその部分については優先度が低いかなと。スケールやテストの自動化などのほうが優先されているかもしれません。

Erisプロジェクト

その部分ができてくると大規模なクラスターでの実装も見えてくる感じですね。少し話題を変えてLINEにおけるDevOpsについてお聞きしたいんですが、LINEではDevOpsは実現できていますか？

西脇：インフラストラクチャーチームにおいてはコードを書くエンジニアもいますし、運用のエンジニアとも近い感じですので、DevOpsは実現できているのかなと思いますね。ただインフラの上で動くアプリケーションについては、チームによってバラバラかなと。運用のエンジニアが入っているチームもありますし、チームによっては上手くできている部門もあると思います。

室井：新人の私の感覚ですと、デベロッパーチームと運用チームはコミュニケーションが上手くいっているという印象があります。なんて言うか難しいですけど、クリアーに伝わっているというか。お互いのミッションを理解した上で、ちゃんと伝えたいことが伝わっているという。

それは前職の組織ではできていなかったからということからくる印象ですか？

室井：それはノーコメントで（一同爆笑）。

大爆笑するLINEのインフラストラクチャーチーム

LINEのインフラストラクチャーチームの目指す方向性が垣間見えたインタビューとなった。セッションでは、プレゼンテーションを行うことで他のユーザーからも注目され、SIGでのディスカッションにおいてもファシリテイターから意見を求められていたことからも分かるように、セッションで一方向に情報発信を行うだけではなく、そこを出発点として他のデベロッパーとの対話が生まれるところにオープンソースコミュニティのダイナミズムがある。今回のように、自社が経験したトラブルの対応を発表する以上に得るものが多い。日本のユーザー企業も、LINEのオープンソースコミュニティに参加する姿勢を参考にして、ぜひコミュニティに飛び込んで欲しいと切に思う。