「フルスタック地獄で完全な自動化は難しい」 国立情報学研究所はクラウド運用効率化をどう進めている？：「Jenkinsおじさん」を生み出さない仕組み

ますます複雑化するIT環境でどう運用管理の効率を高めていくか。2020年7月末に開かれた「Cloud Operator Days 2020」に登壇した国立情報学研究所のクラウド運用チームに所属する谷沢智史氏は、クラウド運用の効率化に向けてどう取り組んでいるか紹介した。

[石川俊明，＠IT]

　複雑化するIT環境において、運用管理の効率化を実現する手段の一つとして「インフラ運用のコード化」（Infrastructure as Code：IaC）が重要視される中、自動化に対する期待が高まっている。一方で、実際の運用現場は複雑だ。事業部門からの要望対応、突如発生した障害の解消作業など非定型業務が多々ある中で、自動化はもとよりIaCを実現させることも容易ではない。

　2020年7月に開かれた「Cloud Operator Days 2020」では、国の研究機関として効率的な研究環境の構築と運用が求められる国立情報学研究所（以後、NII）でクラウド運用チームに所属するボイスリサーチ 取締役の谷沢智史氏が登壇。クラウド運用にまつわる課題にどう取り組んでいるのか紹介した。

「真のフルスタック地獄」で完全な自動化は難しい

　NIIでは、オープンソースソフトウェア（OSS）のクラウド運用基盤「Eucalyptus」を用いてVM（仮想マシン）を提供するプライベートクラウドを構築、運用していた。しかし利用者から「性能測定や計算処理をするので仮想マシンではなく物理マシンを提供してほしい」という要望を受け、OpenStackをベースにベアメタルプロビジョニング部分を独自実装したプライベートベアメタルクラウドに移行。現在は、OpenStackのベアメタルプロビジョニング用コンポーネント「OpenStack Ironic」や、SDN（Software-Defined Network）を実現する「OpenFlow」を活用しながら研究者にベアメタルクラウドを提供している。

　谷沢氏は現在の状況を「真のフルスタック地獄」と振り返る。

　「OpenStackはさまざまなモジュールで構成されている。過去のバージョンでは、モジュールごとの相性で苦労した。また最近だと、OpenStack Ironicでノードをプロビジョニングできない問題があった。調査の結果、BIOSのバグだと分かったが、BIOSのバージョンアップデート中に作業ミスをして別のバグを踏んでしまうなど、BIOSやハードウェアのレベルからOpenStackのようなサービスレベルまで理解し対応しなければならない『真のフルスタック地獄』の状況にある」

　NIIのクラウド運用チームでは、効率的な運用を目指すために全てを自動化するのは難しいとして、インフラエンジニア間のスキルトランスファーを促す仕組みの構築のために試行錯誤してきたという。

「ニンベンの付いた自働化」に着目

　そこで着目したのが「異常の見える化」と「人間が介在する自動化」だ。この考え方は『トヨタ生産方式』にも通じるものがあるという。

　「『トヨタ生産方式』は自動化について『ニンベンの付いた自働化』という言葉を使っている。これは製造現場において、機械や品質の正常／異常を人間が付きっきりで監視・対応するのではなく、異常があったら機械が自主的に機械を止め、人間が異常を正常に戻すことでコストを抑えるという考え方だ。インフラエンジニアはインフラ基盤を1回作ったら終わりではないし、ソフトウェア周辺環境の変化も早い。この変化は基本的に良い方向に向かっているが、悪い方向に向いてしまうこともある。未知の異常が発生することを前提に考えた際、『トヨタ生産方式』にあるような『人間が介在する自動化』（ヒューマンインザループ）を意識するようになった。これは自動化というよりも機械化といった方がしっくりくる」

　NIIのクラウド運用チームはこの考え方を「Literate Computing for Reproducible Infrastructure」（LC4RI：再構築可能なインフラのための文芸的機械化）としてまとめ、クラウド運用に生かしているという。

文芸的機械化をどのように実践しているのか

　では、文芸的機械化をどのように運用現場で適用しているのか。NIIではコードの記述や実行が可能なOSSのWebアプリケーション「Jupyter Notebook」とOSSの構成管理ツール「Ansible」をベースに実現している。

　「データサイエンティストが利用するツールとしての印象が強いかもしれないが、Jupyter Notebookはドキュメントとコードを併記できる。担当者の作業内容や作業結果、どのようなログを見てどのように判断しているかをJupyter Notebookで全てまとめておくようにするというものだ」

　担当者が作業のために実行したコマンドやその結果をJupyter Notebookにまとめることで手順とその結果を見える化する。頻繁に行う作業については、Ansibleの「Playbook」コマンドや、CI（継続的インテグレーション）／CD（継続的デリバリー）ツールの「Jenkins」を用いて機械に実行させるという流れだ。

環境構築の手順からトラブルシュート時の作業内容までさまざまな情報を蓄積

　「自動化について、ゴールに定めて運用効率化を図っていくにしても、どのしきい値になったら何をするのかという設計部分が難しい。Jupyter Notebookにまとめておくことで、自動化する際の参考になる。また、担当者は問題が起きてから初めて動いているコードを見るということも少なくない。Jupyter Notebookに全作業を記録しておくことで、問題が起きる前と後の証跡としても役立つ」

Jupyter Notebookを運用管理に利用する3つのメリット

　谷沢氏は、運用管理にJupyter Notebookを利用する3つのメリットを紹介した。

　1つ目は、機械と人間の役割分担ができることだ。

　「障害発生時のログの調査や保全を全自動にすることは難しい。ログを調査してソフトやハードのどちらに原因があるのかを突き止めるには人間が必要だ。自動化が難しい部分のある状況では文芸的機械化を実践することで人間がやるべき部分と機械がやるべき部分を分けて考えることができる」

　2つ目は、人間同士のコミュニケーションを助けることだ。

　「運用管理でよくあるのが『ログ調べといて』と依頼されるケースだ。どこに何のログがあり、どのログから調査すべきかは知識がないと難しい。またドキュメントが用意されていても、ログの見方が書いてあるだけで、そのログをどう解釈すべきかが書いていないこともある。Jupyter Notebookを用いることで、ログの見方とともに知識や経験の部分をまとめてコミュニケーションできる」

　3つ目は、IaCの課題解決につながることだ。

　「IaCを実践して自動化を目指しても、トラブルシュートを中心に手作業で進める部分が残ってしまうことがある。『Jupyter Notebookで手作業も機械化する』というスタンスで作業記録を残しておくことで、自動化のめどが見えやすくなる。また、IaCを自動化する部分のノウハウが属人化してその担当者がいないとできない『Jenkinsおじさん』のような問題も、説明やコードを記述しておくJupyter Notebookがあれば防ぐことができる」

約1000のNotebookを蓄積

　現在のクラウド運用チームは4人で、全員が別々の企業に属しているという。こうした状況でも、Jupyter Notebookで蓄積された約1000のNotebookを活用することで円滑な情報共有ができているという。

　また最近あった事例として、ベアメタルサーバに「CentOS 7」をデプロイした後、1回目は起動できても、2回目以降は「Grub rescue」に遷移して起動できなくなる不具合が起きた例を紹介。原因はCentOS 7のブートローダー「Grub 2」のバグだったが、Jupyter Notebookにイメージ作成のプロセスや各プロセスの初期設定を記録していたため、このバグの発見に役立ったという。

　「Jupyter Notebookに記録されている内容を確認することで、目の前で起きている不具合に対して『今までと違う運用をしていたんじゃないの？』『こうした作業をしちゃったんじゃないの？』という疑惑を晴らすことができて問題解決に大きく貢献した」

　谷沢氏は次のように話し、講演を締めくくった。

　「Jupyter Notebookを用いた運用のメリットを感じている一方で、単純な作業まで記録するのか、どういったフォーマットでまとめるかという規律の部分での課題を感じており、試行錯誤を続けている。Jupyter Notebookを円滑に活用するための『LC4RI用ツール全部入りイメージ』を公開しているので、文芸的機械化という運用手法に興味がある人は使ってみたり、Pull Requestを送ったりスターをつけたりしてもらえたら幸いだ」