オープンなコミュニティ「Rubrik Build」開設、バックアップ製品のAPI連携による「価値」をアピール
Rubrikの「APIファースト」が生む価値、技術責任者に聞く
2019年03月25日 07時00分更新
バックアップ／データ保護製品ベンダーのルーブリック（Rubrik）が2019年3月15日、オープンソースコミュニティ「Rubrik Build」の開設を発表した。同社のデータ保護製品とサードパーティー製アプリケーションや自動化ツールとのAPI連携機能を開発／公開したり、それを利用／改善／学習したりするエンジニアを増やすことを目的とした取り組みだ。
「Rubrik Build」コミュニティのWebサイト（build.rubrik.com）
発表の中では、ルーブリックが設立当初から製品設計において「APIファースト」のアーキテクチャ／アプローチを取ってきたことが説明されている。同社チーフテクノロジストのクリス・ウォール氏も、今回スタートしたRubrik Buildはそうしたアプローチの延長線上にあり、API活用によるオペレーションの自動化などをユーザー企業のエンジニア自身が推し進められるようにするものだと説明する。今回は来日した同氏に、APIファーストアプローチの狙いやRubrik Buildの具体的な取り組みを聞いた。
米ルーブリック チーフテクノロジストのクリス・ウォール氏
コンポーネント間がAPI連携しているルーブリックのアーキテクチャ
ルーブリックはシンプルで自動化されたバックアップ／データ保護製品の開発を目的として、2014年に設立された新興企業だ。バックアップサーバー／ストレージ機能を一体化した物理アプライアンスのほか、サードパーティー製サーバーで動作するソフトウェア、ブランチオフィス向けの仮想アプライアンス、パブリッククラウド上で動作するソフトウェアと、複数拠点に分散するこれらの製品群をクラウドから統合監視／管理するSaaS「Polaris」を提供している。
「APIファーストのアーキテクチャ」とは具体的にどんなものなのかをウォール氏に尋ねたところ、まずはルーブリック製品を構成するソフトウェアスタックについて説明してくれた。この「Cloud Data Management（CDM）」スタックを構成するコンポーネント群は、物理アプライアンス、仮想アプライアンス、クラウドソフトウェアとも基本的に同じである。
CDMは、ユーザーインタフェースやAPIを提供する「インタフェース」層、データのライフサイクル管理やグローバル検索機能を提供する「ロジック」層、分散ファイルシステムやクラスタ管理といったデータ保存の基盤を取り扱う「コア」層という3つのレイヤーに分かれている。
この各レイヤーには複数の機能コンポーネントが含まれる。その詳細は割愛するが、ポイントは各コンポーネント間が「API経由で」連携しているという点だ（もちろんSaaSのPolarisともAPI連携している）。こうした設計を指して、ルーブリックではAPIファーストのアーキテクチャと呼んでおり、設立当初からこうした設計開発方針をとってきた。
ルーブリック「Cloud Data Management」スタックのアーキテクチャ図。各機能コンポーネントはAPIを介して連携動作する
「ルーブリックの創立メンバーは、グーグルやフェイスブックといったハイパースケールなクラウド企業、またオラクルのようなエンタープライズフォーカスの企業の出身者たちだ。彼らは新しく立ち上げる企業で、その両方の世界で学んだことを生かしたいと考えていた。したがって製品におけるAPIファーストのアプローチも、設立当初から意識していたものだ」
ウォール氏は、アマゾン・ドットコムCEOのジェフ・ベゾス氏が2002年、全社に向けて発した“API化指令”を引き合いに出した。これはアマゾンが提供するサービス（データや機能）は例外なくすべてAPIで公開すること、サービス間の連携も公開APIを介して行うこと、外部開発者もこのAPIを利用できるようにすること、といった内容の指令だ。
「これは私見だが、ベゾス氏はAPIの公開によってアマゾンのサービスをインタラクティブ、プログラマブルなものにすることで得られる価値をよく理解していたのだと思う」
もうひとつ、最初の段階からAPIを前提にしてきたことのメリットも大きいとウォール氏は説明した。既存のソフトウェア製品をAPI対応にしようとすると、既存コードのレイヤーの上にAPIのレイヤーを“付け足す”ような形になってしまう。「あるいは、ソフトウェアをゼロから作り直すかしかない」。
一方でルーブリックの場合は、もともとも内部のコンポーネントどうしがAPI経由でやり取りするよう設計されているので、ここにそのまま外部システムが接続して、内部コンポーネントと同じように機能やデータを利用することができる。「ルーブリック（の内部コンポーネント）もユーザー（外部システム）も、API経由で取得できるものは基本的に同じだ」とウォール氏は説明する。
既存コードに“APIレイヤー”を付け足す形（左）の場合、APIレイヤーが仲介し処理をする必要がある
「リカバリテストの自動化」など、サードパーティ製品とのAPI連携
ルーブリックとAPI連携するサードパーティー製品として、最もポピュラーなものは「VMware vRealize Automation」だという。vRealize Automationは、社内エンドユーザー（たとえば開発者など）が自ら仮想マシンをプロビジョニングできるよう、セルフサービスカタログや自動プロビジョニングの機能を提供する製品だ。これにルーブリックを連携させることで、プロビジョニングした仮想マシンのデータ保護もユーザー自身で設定できるようになる。
そのほか、マイクロソフトの「PowerShell」や、ITサービス管理などの統合ワークフローツールである「ServiceNow」と連携させるユースケースも多いという。前者では、バックアップした仮想マシンイメージを使って起動テストを実行し、OSやアプリケーションが破損しておらず問題なくリストアできることをチェックする。
「PowerShellのユースケースを導入しているユーザー企業は、たいてい毎晩このチェック処理を行っている。これまで、バックアップ処理を行ったあとのリストアテストは面倒でないがしろにされていたが、こうして自動化できれば面倒ではない。IT管理者も毎晩安心して眠れる、というわけだ（笑）」
もうひとつ「楽しいユースケース」として、ウォール氏は「Red Hat CloudForms」とのAPI連携を紹介してくれた。これは、Rubrikを複数のクラウド環境に展開する作業を自動化するもので、各環境に展開するだけでなく構成や設定もすべて自動化できるため、「今使っているすべてのデータセンター、クラウドに対して、まったく同じRubrik環境を展開できる。一貫性と信頼性が担保できる」とウォール氏は説明した。
Rubrik Buildを通じて、API連携で得られる「価値」をアピールしたい
ルーブリックでは今回のRubrik Build立ち上げの前から、ユーザーのAPI活用を促すためにソフトウェア（SDKなど）の配布を行ってきた。ウォール氏によると、たとえばPowerShell向けSDKは過去3年間で4700回ダウンロードされており、コードには800回以上の改善（コミット）がなされている。またAPI利用のためのプロジェクトはすでに55あり、今年さらに21のプロジェクトがリリースされる予定だと述べた。
Rubrik Buildは、こうした動きをさらに加速させるための取り組みになるという。SDKやコードを提供するだけでなく、トレーニング、ドキュメント、ユースケースを提供するものになるという。「つまりどうやってAPIを使い、成功すればよいのかを、より多くの人に見て、理解してもらうためのものだ」。
ウォール氏は、データセンター／インフラエンジニアにとって「APIはまだまだ新しい存在だと考えている」と語る。そうした障壁をなくしていく狙いもある。また、APIの利用方法だけでなく具体的なユースケースも紹介することで、そこで生まれる「価値」を理解してもらえるのではないかと期待しているという。
Rubrik BuildのWebサイトを見ると、ユーザーが自ら開発するためのSDK（PowerShell、Python、Goに対応）、vRealizeやAnsible、TerraformなどとRubrikの統合ツール、さらに「SplunkによるRubrik環境のモニタリング」「vRealizeを通じたプロビジョニングと自動保護設定」といった具体的なユースケースという、粒度の異なる3パターンでコンテンツが用意されている。また世界各地で行われるDevOpsや運用自動化関連のカンファレンスへの参加スケジュールも公開されていた。
「APIは、さまざまな作業をシンプルにするメソッドを提供するものだ。テクノロジーで優位に立ちたいのであれば、API活用がスキル高度化のチャンスになる。Rubrik Buildはオープンなコミュニティであり、インフラエンジニアでもソフトウェア開発者でも、誰でも参加してほしい。データ保護についての理解を深めるための良い出発点にもなると思う」
