Pivotal Cloud Foundryを選んだ理由として佐野氏は、既に多くの企業で採用されている点を挙げた。加えてOSSのクラウド構築基盤「OpenStack」やサーバ仮想化ソフトウェア「VMware vSphere」など複数のIaaSや仮想化基盤で動作するなど動作環境が幅広いこと、好みの開発言語やデータベースなどを追加・拡張して独自のPaaS環境としてカスタマイズしやすい点も大きかったという。

　一方のConcourseの選定理由として挙げたのは、次の3つの特徴だ。まずは「Simple」（単純さ）で、開発・デリバリー作業（タスク）の流れを示すCI／CDパイプラインの定義を全てYAMLファイルで管理でき、構成管理が容易になる。次に「Scalable」（拡張可能）なことで、CI／CDパイプライン内の各タスクを実行する「Worker」のインスタンス（コンテナ）を追加するだけで容易に拡張できる。そして3つ目が「Reproducible」（再現可能）なことだ。タスク実行環境をコンテナで提供するため、コンテナイメージさえあればどこでも再現できる。

　もちろんPivotal Cloud FoundryやConcourseを導入したからといって、基盤構築や運用の全てを自動化できるわけではない。それでもミドルウェアのランタイム（実行環境やライブラリ）部分をワンパッケージで提供する「Buildpack」というCloud Foundryの機能を利用すれば、少数のプラットフォーム担当者でバージョンアップや脆弱（ぜいじゃく）性パッチの適用などもできるようになる。トラフィックやCPUの使用率にあらかじめしきい値を設定しておき、それを超えた際に自動的にインスタンスを増やし、負荷が下がったらインスタンスを減らすといったオートスケールも可能になる。こうしたプラットフォーム側の操作をサービス担当者は全く意識する必要はなく、「ワンコマンドでソースコードをアップロードするだけで、その言語に合わせた環境を簡単にデプロイ（配備）でき、Webサービスを立ち上げることができます」と佐野氏は強調した。

　この基盤で2017年度末までに17種の社内ツール、28種の一般ユーザー向けサービスが本番稼働を迎える計画だ。「2018年度以降は、さらにこの数倍の開発プロジェクトが動き始めることになります」と、佐野氏は今後の見込みを示した。

全ての社内プラットフォームの“マーケットプレース化”を推進する

　実際のところ、ヤフーはどのような体制でPivotal Cloud FoundryならびにConcourseの活用を推進しているのだろうか。佐野氏によると、Googleがクラウドビジネスで提唱している「CER（顧客信頼性エンジニアリング）」と「SRE（サイト信頼性エンジニアリング）」の2つのチームを、同社も社内に設置した。

　CREチーム（8人）のミッションは、開発者によるプラットフォーム移行の不安を取り除くこと。Pivotal Cloud Foundryの効率的な利用方法を提案し、困難な課題を解決する。例えばCI／CDパイプラインの整備、Pivotal Cloud Foundry管理ツールの開発・保守、ユーザー（社内のエンジニアなど）からの問い合わせサポート、セミナーなどのユーザー教育に当たる。

　一方のSREチーム（7人）は、Pivotal Cloud FoundryおよびConcourseの信頼性向上に注力し、障害予防や自動化促進に努めてシステムの信頼性を高める。例えばPivotal Cloud Foundry本体やBuildpackのアップデート、新規クラスタの構築、運用監視、障害対応などが主な役割となる。

　そしてこの2つの社内チームの活動を補完すべく導入しているのが、Pivotalが提供する「Business Critical Support」と「Professional Service」のサポートである。

　こうした運用体制の下、「開発者がより簡単にプラットフォームを利用できるようにするため、あらかじめプラットフォームを登録しておくことで即座にPivotal Cloud Foundryで利用できる“マーケットプレース化”を、全ての社内プラットフォームに対して推進していく」と佐野氏は語った。

ヤフーの主要プラットフォーム（左）、マーケットプレース（右）《クリックで拡大》

　また現在、Pivotal Cloud Foundryの標準管理ツールでクラスタごとに個別に権限の管理（設定・変更）をかけていたものを、複数クラスタに一括で権限を管理できるツールを開発した。社内の権限管理ツールとも連携し、Pivotal Cloud FoundryのACLを一元管理する。その他、障害発生時のアラートを受け取って自動で復旧させる仕組みづくりも進めており、将来的に全ての運用系作業の自動化を目指す。さらにはクラスタの正常稼働に必要なメトリクス（数値指標）を可視化することで、問題発生のアラートをトリガーとしている後追い的な対応から脱却し、より余裕を持った先回り対応に移行していく計画だ。

　Pivotal Cloud Foundryの導入に当たっては苦労もあった。既存システムで使用していた、全社システム共通処理用のデーモン（常駐プログラム）のプロセスをPivotal Cloud Foundryへ移行する際、BuildpackベースのCloud Foundryアプリケーションではこのデーモンプロセスを利用できないという課題に直面した。オンプレミスやIaaSの仮想マシンでは問題がなかったIPアドレスベースのセキュリティポリシー（ファイアウォール設定など）についても、PCFは複数のサービスがマルチテナントでテナントに乗るため、サービスごとにIPアドレスを定められず、想定通りのセキュリティポリシーが適用できない場合がある点でも苦労した。標準化でも課題になった。Pivotal Cloud Foundryは利用可能なミドルウェアや開発言語が多様だが、他のプラットフォームと連携する場合は専用のライブラリを用意する必要がある。PaaSは自由度が高いとはいえ、規模によってはある程度の標準化をしておかないと苦労しそうだ。

　佐野氏は「クラウドサービス化では単に開発環境を提供するだけでなく、現行ポリシーの見直しや体制づくりも含めて準備することが重要です。特に開発者に対してはセルフサービス化を推進し、運用担当者に対しては可能な限り自動化を図ることで、PaaSのメリットを最大限に享受できます」と訴求し、基調講演を締めくくった。