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

本連載では、「インフラの、特に基盤寄りの立場からSRE（Site Reliability Engineering）の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」について、リクルートの新たなインフラ基盤を例に見ていきます。今回は、Fleetの具体的な仕組みや取り組みを紹介します。

[北野太郎，リクルートテクノロジーズ]

　本連載「SREの考え方で“運用”を変えるインフラ基盤 大解剖」では、「インフラの、特に基盤寄りの立場からSRE（Site Reliability Engineering）の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」に悩んでいる方々に向けて、リクルートの新たなインフラ基盤である「RAFTEL Fleetサービス（以下、Fleet）」を作ることになった背景と狙い、そして「いかにしてFleetを作り上げたのか」について順に紹介しています。

　前回、Fleetが生まれた背景と、目指す思想を紹介しました。Fleetは、利用者に対する以下の課題を解決します。

• 即時提供によるリードタイムの解消
• 開発者が希望する好きな設定を可能に
• そもそも依頼者が自ら設定することで申請を不要な世界観に

　その上で、運用者に対しても以下のメリットをもたらします。

• 運用作業をより効率的に
• 高い信頼性によるダウンタイムの低減

　今回は、Fleetはこうした特徴をいかにして実現しているのかについて、具体的な仕組みや取り組みとともに紹介します。

利便性を提供するコンソールと自動化、信頼性を支える基盤

　前回紹介した通り、Fleetは以下の2つの構成要素で成り立っています。

• Fleet Management Console（Fleetコンソール）
• Fleetインフラ基盤

　例えば自動化1つとっても、その一連の自動化を支える手段を提供する「インフラ基盤」と、それを組み合わせて制御する「Fleetコンソール」の2つが必要になります。Fleetを支えるこの2つは、お互いに密接な関わりを持っています。

　Fleetでは、当初からこの2つの要素は重要であると考えており、基盤と管理画面を別々に設計するのではなく、当初の目的や思想に準じつつお互いが連携しながら設計を進めていました。

　高い信頼性を持ちながら自動化を支えるFleetインフラ基盤については次回紹介するとして、今回はその基盤を操作するWebコンソールである「Fleetコンソール」を紹介します。

マイクロサービスアーキテクチャで開発の高速性とシステムの堅牢性を実現する

　冒頭で触れた通り、Fleetでは利用者が直接操作することでインフラを自由に設定できます。そのため、利用者がインフラを操作するためのGUIは絶対に必要になると考えていました。このGUIをFleetコンソールとして開発、提供していることになります。具体的には、利用者が以下のような操作を行えます。

• 仮想マシンの作成／削除、スケールアップ／スケールダウン
• ロードバランサーの作成、設定変更、削除
• ファイアウォールの設定
• NFSボリュームのマウント／アンマウント
• Ansibleによるミドルウェア設定
• ユーザー管理

　Fleetコンソールは、Fleetインフラ基盤に対してさまざまな制御を行う、唯一にして重要なサービスです。コンソールがなければ利用者はインフラを操作できないため、高い信頼性を求められます。同時に、さまざまな機器に対して操作を行うという機能の多様さを持ち合わせています。それ故に開発も難しく、限られた期間の中でさまざまな機能を効率的に開発しながら、結果的に完成するシステムの信頼性を担保したいと考えていました。

　Fleetコンソールは、それらの解決策として、「マイクロサービスアーキテクチャ（Microservice Architecture）」を採用しました。マイクロサービスアーキテクチャとは小さなサービスの集まりとしてアプリケーションを開発するアプローチのことで、2014年にジェームス・ルイス（James Lewis）氏とマーティン・ファウラー（Martin Fowler）氏が、ファウラー氏自身のサイトにおいて発表した記事から広まりました。

　一般的にマイクロサービスアーキテクチャにはさまざまなメリットがありますが、特にFleetコンソールにおいてマイクロサービスアーキテクチャを採用した理由は以下の通りです。

開発対象の分業容易化

　小さなサービスに分けて、それぞれを独立したアプリケーションとして動かすため、それぞれの単位で開発を進めやすくなりました。特にFleetコンソールは後述の通り操作対象機器が多いため、その単位で処理を明確に分けることで見通しが良くなることにも貢献しています。

　結果として、それぞれのサービス単位で設計、実装が行いやすくなり、開発効率は向上しています。

対象機器ごとの耐障害性と保守性の向上

　Fleetコンソールが操作対象とする機器はさまざまです。詳細は連載第3回で説明しますが、仮想マシンをつかさどる「VMware vSphere」、ネットワーク機能をつかさどる「VMware NSX」、ロードバランサー機能をつかさどる「BIG-IP VE」、NetAppストレージ、その他DNSサーバやLDAPサーバなどの共通機能など、広範にわたって設定を指示します。それぞれの機器と、それぞれの機器に指示をするアプリケーションでサービスを小さく分けることで、それぞれが独立して動くようになりました。

　結果として、機器ごとのメンテナンス作業時には影響範囲をサービス単位で考えられるようになり保守が行いやすくなったことに加え、障害時も影響範囲を限定できるようになります。

コマンドラインツールの提供によるさらに高度な自動化の実現

　実際に利用者がインフラに対する操作を行う場合、必ずしも画面上で操作を行うことが最適とは限りません。例えば、必ず決まった時間帯にシステムを増強しなければならない場合や、開発環境を複数作りたい場合、また利用者が開発時に個人の開発環境を作成する場合などの決まった操作を行う場合、毎回コンソールの画面上から逐一操作を行うのは負担になってしまいます。

　こうした、一度に環境そのものを作りたいような場合には、コマンドラインツールが役に立ちます。Fleetでは、これまで紹介したFleetコンソールの他にコマンドによってインフラを操作できるコマンドラインツールも提供しています。

　これは、厳密にはマイクロサービスアーキテクチャというよりは「APIサーバ」化していることに起因していますが、マイクロサービスアーキテクチャを設計する上で事前に考慮していたことであり、そのおかげで実現できたことでもあります。

　これらの通り、マイクロサービスアーキテクチャには開発のスピードアップの他にもさまざまな恩恵があることが分かります。