操作の快適性と自動化を支えるインフラ基盤のマイクロサービスな管理コンソール：SREの考え方で“運用”を変えるインフラ基盤 大解剖（2）（2/2 ページ）

マイクロサービスとしてのFleetコンソールの構成

　先述のメリットを享受することのできるFleetコンソールは、以下のプロダクトやサービスによって構成されています。少しではありますが、構成のポイントを紹介します。

APIサーバ群：Django（Python）

　マイクロサービスは、コンポーネント単位で自由にプロダクトを選べるのがメリットでもありますが、無駄にプロダクトを増やしてもメンテナンスコストが増えるだけです。特別な理由がない限り、利用する技術要素は少ない方がシンプルになり、メリットが多くなります。

　FleetにおけるAPIサーバは、これまでに紹介した通り操作対象の機器ごとに分かれていますが、そのいずれもDjangoフレームワーク（Python）によって作られています。Python自体が一般的に利用が多く、導入が容易であることに加え、それぞれの機器に対して操作できるライブラリも用意されていることが選定のポイントでした。

データストア：PostgreSQL、Neo4j、Elasticsearch

　一般的に「データストア」といっても、格納する情報はさまざまです。例えば認証情報や、操作対象のインフラの設定情報、利用者の操作ログなどさまざまな情報がある中、必ずしもRDBMSが最適であるとは限りません。一般的にRDBMSで済むものはPostgreSQLに格納していますが、インフラ構成情報はNeo4j、利用者の操作ログはElasticsearchに格納しています。

　Neo4jはあまりなじみがないかもしれませんが、「グラフデータベース」と呼ばれるもので、「ノード（node）」「要素（property）」「関係性（relationship）」の3つから構成されます。RDBMSと違い、それぞれのノードのつながりを表現するものです。

　FleetコンソールではこのNeo4jにインフラ構成情報、すなわち仮想マシンやネットワーク設定、ストレージ設定などを格納しています。例えば、1つの仮想マシンはスペック情報、ネットワーク、NFSマウントなどのさまざまな構成要素を持ちます。これらは仮想マシンを「ノード」とし、それにひも付く設定を「要素」とすることができます。加えて、1つのネットワークセグメントに属する仮想マシン同士を「関係性」でつなぐこともできます。

　Fleetコンソールでは、利用者がさまざまな軸でインフラ情報を取り出すことが予想されたため、単純なRDBMSではなく、Neo4jによるグラフデータベースを採用することにしました。例えば、以下のような情報を自由に取り出すことができるようになります。

• 特定のネットワークセグメントに属する仮想マシンを調べる
• 特定の仮想マシンのスペックを調べる
• 仮想マシンがマウントしているストレージの一覧を調べる、特定のストレージをマウントしている仮想マシンの一覧を調べる

　Elasticsearchは「全文検索エンジン」と呼ばれるもので、文書の検索に向いています。Fleetコンソールでは利用者の操作ログを格納しており、検索を行いやすいようにしています。利用者自身が「いつ、誰が、どんな操作を行ってインフラを変更したのか」を調査する可能性があると考えたため、操作内容だけではなく操作ログに対しても検索を行えるようにしています。

　同時に、この操作ログは提供者側からしても貴重な情報源になります。例えば、「どんな操作が多く、どの操作につまずいているか」「どの機能が不安定であるか」「どれだけの時間を要しているのか」を知ることができるため、今後の改善につなげやすくなるのです。こうした分析は、Elasticsearchにログを格納した上で、Kibanaで可視化することで実現しています。

ワークフロー：StackStorm

　例えば、「仮想マシンを作成する」という処理1つをとっても、実際には非常に多くの処理を含んでいます。

• OS
• マシンスペック（CPU、メモリ、ディスク容量）
• ネットワーク設定（IPアドレッシング、通信設定、ルーティング）
• カーネルパラメーター
• 認証設定（LDAPなど）
• DNS
• ウイルススキャン

　しかし、実際の開発において、これらの設定を逐一細かく設定したいケースは、それほど多くはありません。利用シーンの大半は、「設定のきめ細かさ」よりも「お手軽に設定できること」の方が優先されると予想していました。

　実際、Fleetにおいても、「利用者にこれらの設定を細かく選択させることよりも、選択すらさせずに自動で設定しておく方が望ましい」ことがヒアリングなどにより分かりました。同様に、これらの基本的な設定はリクルートのセキュリティルールによって定められる部分も多く、必ず投入しなければならない制約も多くあります。

　そのためには、これらの一連の設定を利用者にほとんど選択させることなく、つなぎ合わせて自動化する必要があります。Fleetではこうした一連の処理を、「StackStorm」というワークフローエンジンによって実現しています。先述の設定を自動化し、利用者が細かい部分までを気にしなくとも、自動的に欲しいインフラが手に入る状態を実現しました。

基盤：Rancher、Docker

　ここでいう「基盤」とは、Fleetコンソールを動かす土台のことを指します。先述の通り、非常に多くのマイクロサービスが動作することから、それらの管理も複雑化していきます。それらを、DockerとRancherによるコンテナ技術によって管理することで、自動かつ少コストで運用することを実現しています。

利用者が期待する機能をコンソールで提供するための取り組み

　こうした工夫によって作られるFleetコンソールも、利用者が期待する形で完成しないことには意味がありません。Fleetコンソールとしての機能が必要十分であるためには、「利用者が、そのコンソールを利用して、どんなことを行いたいのか」を把握する必要があります。しかし、いくらFleetを提供する立場から利用者が期待する機能を想像したとしても、それが本当に必要十分であるかどうかは実際に使ってみてもらわないと分かりません。

　例えば、一言に「仮想マシンを作成する」といっても、「OSは何にするのか」「CPU、メモリなどのマシンスペックはどうするのか」……など、細かい検討課題は尽きません。他にも、提供者の思いもよらない機能を利用者が期待しているかもしれません。

　そのため、Fleetは開発時点からアジャイル開発を採用し、実際にFleetを利用するリクルートのとあるサービスを「ファーストサイト」として連携させながら開発を進めていきました。具体的には、逐一機能を提供してはファーストサイトの利用者（インフラ担当者や運用者）からフィードバックを得て、次回その機能を取り込んでいく……という工程を繰り返し、それによって完成度を高めています。

利用者が快適にコンソールを使うためのユーザーインタビュー

　こうして作られたFleetコンソールを使えば、誰でも自ら好きな設定を投入でき、リードタイムを解消させることができるのでしょうか？

　前節の通り、実際に利用者に触ってもらいながら機能的に満たしていったとしても、実際は不十分であると考えていました。というのも、開発当初から付き合ってきた「ファーストサイト」は、いわばFleetコンソールに「（悪い意味で）慣れてしまった」可能性があるからです。

　どんなにコンソールが不便であったとしても、何度も触るうちにその不便さを覚えてしまうということです。ファーストサイトの利用者にとってはそれでもいいかもしれませんが、初めてFleetを触る他の利用者にとって、それが快適なものである保証はありません。

　これでは、業務システムにありがちな「機能はそろっているがすこぶる使いづらいシステム」が出来上がってしまう可能性があります。提供者と利用者は、知識や背景、そして目的などさまざまなものが異なります。提供者はできるだけ利用者のことを考えて作ったつもりでも、利用者が本当に欲しているものは「本人にしか分からない」、あるいは「本人ですら明示的に言語化できない」ことがほとんどです。利用者との隔たりが埋まらないまま作られてしまったシステムは、せっかく機能は満たすにもかかわらず、結果的に「使えない」という烙印（らくいん）を押されてしまうという悲しい結果をもたらします。

　Fleetコンソールは、当初からそうした状況を予想していました。こうした状況を防ぐべく、社内のUX/UI（ユーザーエクスペリエンス／ユーザーインタフェース）専門の部署に協力を仰ぎ、Fleetコンソールがより快適に利用できるための取り組みを進めました。

　具体的には、先述のアジャイル開発の中に「ユーザーインタビュー」という取り組みを設けました。これは、「実際に想定される利用者にコンソールのβ版を触ってもらいながら、その中で改善点や問題点を洗い出す」ものです。面白いのは、利用者が触った後に一方的なフィードバックを受けるのではなく、「利用者が触っているところをじかに観察する」ことです。これにより、ユーザーは「どこで悩むのか」「何を考えているか」といった細かい課題が如実に分かるようになります。

　提供者からすると「当然、次はあそこにあるボタンを押すだろう」「この後はあの画面に行くだろう」と思っていたものが、思わぬところで立ち止まることを発見し、足りなかった機能やより良い画面レイアウトを見直すことができるようになります。

　具体的には、以下のような流れで進めました。

　こうして得られた改善ポイントは、一方向のフィードバックだけではとても得ることのできない、非常に質の高いものになっています。例えば、以下のような改善点を見いだすことができました。

• 意味のない表示項目を減らし、無駄な情報を表示させないようにした
• とある操作を実行中、その待ち時間に他の操作を行いたいことが分かったため、前述の操作は別ウィンドウで表示するようにした
• 目的の情報にたどり着きやすくするために、一覧情報に対してのフィルタリング機能を実装した
• 分かりにくい項目にツールチップやプレースホルダを追加した

　Fleetでは、実際の利用想定者7人程度に協力してもらい、初回と改善後の2回にわたって効果を確認しています。

より便利に、より簡単にインフラを作るためにコンソールができること

　ここまで、Fleetコンソールを中心に、いかに利用者に対して利便性を提供してきたかと、それを支えるコンソールそのものの仕組みを紹介しました。ここまで紹介した取り組み、そしてそれによって実現したコンソールの機能によって、Fleetはある程度簡単にインフラを構築、設定できるようになりました。

　昨今、アプリケーションとインフラの境界はより曖昧になり、アプリケーション開発者がDockerなどのコンテナ技術を使い、インフラの領域を触れることも多くなりました。Fleetのターゲットとなる利用者はインフラ担当者から、アプリケーション開発者にシフトしていくと予想されます。そうした場合、Fleetに求められるのはアプリケーション開発者向けの機能になるかもしれません。

　Dockerに対応するのはもちろんですが、究極的には「1クリックで環境が出来上がる」ことを目指せば、アプリケーション開発者は、インフラのことを意識せずに、より開発に集中できるかもしれません。今後、Fleetコンソールはより簡単にインフラを作ることができるように機能を拡充する予定です。

　次回は、高度な自動化の手段を提供し、高い信頼性を備えるインフラ基盤にフォーカスして紹介します。