本連載では、「インフラの、特に基盤寄りの立場からSRE(Site Reliability Engineering)の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」について、リクルートの新たなインフラ基盤を例に見ていきます。今回は、インフラ基盤の技術的解説とともに、出始めている成果、今後の展望についてお話しします。
本連載「SREの考え方で“運用”を変えるインフラ基盤 大解剖」では、「インフラの、特に基盤寄りの立場からSRE(Site Reliability Engineering)の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」に悩んでいる方々に向けて、リクルートの新たなインフラ基盤である「RAFTEL Fleetサービス(以下、Fleet)」を作ることになった背景と狙い、そして「いかにしてFleetを作り上げたのか」について順に紹介しています。
前々回はFleetが生まれた背景と解決したい課題を紹介し、前回はFleetの構成要素の1つ「Fleet Management Console」(Fleetコンソール)を紹介しました。
最終回となる今回では、残るもう1つの構成要素である「Fleetインフラ基盤」の紹介とFleetで出始めている成果、今後の展望についてお話しします。
前回も触れましたが、Fleetインフラ基盤は、高い信頼性を持ちながら自動化を支えるものです。大きくソフトウェアコンポーネントと物理コンポーネントに分かれています。
特徴としては、物理コンポーネントのほとんどは、既存のオンプレミスインフラ「RAFTEL」の機器を流用しており、これを下層にしてその上にソフトウェアコンポーネントで仮想的なインフラを作り出している点にあります。
つまりFleetは新規のオンプレミスインフラではありますが、実態としては既存のインフラ基盤の物理資産を生かし、その上に構築した仮想的なインフラとなっています。
これらのコンポーネントには、インフラリソースの払い出しや設定変更を「Fleetコンソール」からオンデマンドに行うことで高速化、自動化を実現できる製品を採用しています。
特に、インフラリソースの払い出しや設定変更に時間を要していた“ネットワーク”に関連するコンポーネントを、仮想化可能、API払い出し可能としたことが既存のオンプレミスインフラRAFTELで実現できていなかった「Fleet」ならではの特色と言えます。
ここからは、「Fleetがいかにしてネットワーク設定の自動化を実現したのか」について、その詳細を3段階に分けて紹介します。
Fleetのコンセプトである「即時提供によるリードタイムの解消」「開発者が希望する好きな設定を可能に」「そもそも依頼者が自ら設定することで申請を不要な世界観に」をオンプレミスで実現するにはどんなネットワークが必要なのか? どんな製品を選ぶべきか? 議論を重ねて導いたわれわれなりの答えが下記です。
この要件に基づき機器選定した結果が図1の構成です。選定のポイントをまとめると下記のようになります。
「初期投資額を抑制する」ために、繰り返しますが、下層にはRAFTELの既存物理機器をそのまま使用しました。
「すぐに作って、すぐに捨てられるネットワークを実現する」ために、主要コンポーネントであるロードバランサーやファイアウォールについては、物理機器ではなく仮想アプライアンス製品(BIG-IP VE、NSX)を導入しました。
「相互影響を排除する」ために、サイト間のロードバランサーについては、各サイト専用に仮想ロードバランサーを割り当てる設計としました。しかし、仮想ロードバランサーはSSL復号が苦手であるため、その機能を物理ロードバランサーにオフロードできる「Crypto offloading」機能を持つBIG-IP VEを選定しました。またBIG-IP VEの選定理由としては、既存のRAFTELがBIG-IPを採用しており、L7トラフィック管理の「iRules」をそのままBIG-IP VEに移行できる利便性も考慮されています。
「APIが充実している」ことから、ファイアウォールについては、NSXを選定しました。「セキュリティタグ」機能でサイト単位でファイアウォールルールを分割することもでき、スケールアウトで拡張が可能なことも選定を後押ししました。
「何の作業を自動化して、何を自動化しないのか」について、その振り分けを行いました。具体的には、頻繁に発生する下記の作業のみ自動化の対象としています。
一方で、実施頻度が低い以下の設定作業は割り切って自動化対象外として、手動運用としました。
Copyright © ITmedia, Inc. All Rights Reserved.