ヤフーの、データフォレスト構想に向けたミドルウェア活用戦略とは：メッセージキュー、APIゲートウェイ、FaaS（2/2 ページ）

[三木泉，＠IT]

メッセージキュー、APIゲートウェイ、FaaSの展開

Pulsarを、これからの通信手法として活用

　ヤフーでは、メッセージキューのOSSであるPulsarを、2016年に利用し始めた。今では多数のアプリケーションで使われている。きっかけは、ヤフーにおけるPaaSやコンテナの利用拡大で、従来のIPベースでの通信に代わる手法が必要になってきたこと。必然的にメッセージキューでの非同期通信に行き着いた。

　ヤフーは、ちょうど米Yahooが開発していたPulsarに着目。一緒にOSS化しようという話になり、ヤフーの開発者がコントリビューターとして加わった。コードは米Yahooのリポジトリで公開した後、Apacheへ移管した。

　Pulsarの開発には、専任チームが関わっており、業務としてやっているという。OSSに関してヤフーは、以前こそ利用一辺倒に近かったが、最近では同社のCTOもOSSコミュニティへの貢献をコミットしていて、会社としてバックアップする機運が高まっている。

　Pulsarが最も優れている点は、やはりマルチテナント化しやすいことだと、福田氏は言う。単一インスタンスを複数のサービスで利用できる。それぞれのサービスで、利用されているトピックやサブスクリプションの管理が行える一方、運用、障害対応が行いやすい。

　「とはいえ、例えばKafkaを使わないというのではない。使い分けが重要。いろいろなものを選択して使える世界がいいと思っている」（福田氏）

Kongは、「社内の全サービスへの入り口」を想定

　一方、「社内のアーキテクチャがマイクロサービス化していく中で、APIを集中管理する機能がないことが課題となってきた」。

　そこで福田氏たちのチームが現在進めているプロジェクトの1つに、APIゲートウェイがある。2017年にKong Enterprise Editionの採用を決定し、2018年5月に試験提供を開始した。2018年10月には本番運用を始める予定だ。

　KongはAPIアクセスを集中的に受け付け、これを適切なAPIエンドポイントへルーティングする役割を担う。同時に認証・認可機能を提供。このためAPIエンドポイント側では、個々に認証機能を実装する必要がない。利用可能なサービスを見つけることのできる、サービスディスカバリ機能の整備も進んでいる。

　また、Circuit Breaker機能も使われ始めている。Circuit Breakerとは「電源ブレーカー」の意味。障害が発生したサービスへのアクセスを自動遮断することで、障害の影響が広がるのを防ぐことができる。マイクロサービスにおけるAPI利用では、必須の機能だ。

　Kongには、カナリアリリースのための機能プラグインもある。これを使って、サービスのバージョンアップや移行を円滑化する取り組みも進めようとしている。

　APIゲートウェイ機能を果たすソフトウェアとしてKongを選んだのは、KongがOSSだったからではないという。

　「APIゲートウェイは、社内の全てのサービスへの入り口になるため、問題が発生すると全サービスに影響する可能性がある。このため、商用製品と、OSSのエンタープライズ版を比較検討し、Kong Enterprise Editionを選択した」（福田氏）

　「APIゲートウェイという分野には、機能が豊富な製品が多い。これらに比べると、Kongの機能はシンプルだが、基本機能に関してはしっかりしていた。また、弊社のサービスに統合しやすく、必要な機能を実装するコストも低い」

　2018年10月にヤフーは、Kongの本番運用を開始する。すなわち、サービスレベルが保証され、実サービスへの適用ができるようになる。前述の通り、潜在的な対象は社内の全サービスだ。

　福田氏はKongを、基本的なAPIゲートウェイ機能の他、例えばWeb Application Firewall（WAF）的に利用したDDoS対策に使っていきたいという。また、後述するが、OpenWhiskとの統合も進めようとしている。

OpenWhisk、まずは短時間バッチへの適用から

　サーバレスのOpenWhiskは、どのような経緯で導入しようとしているのだろうか。

　「パブリッククラウドでFaaS（Function as a Service）が登場し始めたことで、こうしたツールを使いたいというニーズが出てきたこと、また、サービス部門からは『サーバの管理が大変』という声があった。この2つの課題解決がきっかけだ。FaaSを使うことで、インフラ運用に関わるサービス部門側のコストはゼロに近くなってくる」

　ただし、既にプラットフォーム開発本部の他の部署が、Cloud FoundryによるPaaS、Kubernetesを採用したCaaSの提供を進めている。物理サーバや仮想マシンを立てて運用しなくていいという点では、これら全てがあてはまる。

　このうちFaaSは開発者にとっての負担が最も小さいが、よく知られているように、利用に適したアプリケーションは限定される。このため、FaaSといっても選択肢の1つであることには変わりがない。

　「FaaSでできないところはPaaSやCaaSを使うし、IaaSや物理サーバを使う場合もある。あくまでもサービス部門の開発チームが、目的によって道具を選ぶことになる」

　福田氏たちがFaaSソフトウェアとしてOpenWhiskを選んだ主な理由は、「他のFaaSではマルチテナント対応しているものが少ない」（福田氏）ことにあったという。

　福田氏の部署では、OpenWhiskを2016年以来触り続けてきた。

　「当初は十分にスケールしなかったが、Kubernetes対応によって、コマンド1つで規模を拡張できるようになった。このため、今では本番運用に適していると考えている」（福田氏）

　2018年10月にはKongと同様、本番サービスとして提供を開始する予定だ。

　OpenWhiskの導入による効果は、まず短時間のバッチ処理を移行するといったところから見えてくるだろうという。こうしたバッチ処理のために専用の物理サーバを割り当てているならば、FaaSの利用によって廃棄できるようになるからだ。

　とはいえ、長時間の処理ができないFaaSは、それ自体だけでは使いづらい部分がある。そこで10月以降、KongとOpenWhiskの連携を実現したいという。

　「APIを作るときもサーバレスで作れればいいと考えている。これからの時代は、システム間でHTTPでのやり取りが多くなってくる。サーバレスは、HTTP経由での多様なサービスとの連携があってこそ役立つ」

データフォレスト構想には、APIベースの発想が前提となる

　ヤフーは「データフォレスト構想」を2019年度中に事業化しようとしている。これは同社の多様なサービスから生み出されるデータと、社外のパートナーのデータを掛け合わせ、パートナーのあらゆる活動を支援する取り組みだ。

　このためにはまず、社内の各種サービス間で、データおよびサービス連携を現在よりもさらに深める必要がある。その上で、社外のデータやサービスとの連携を進めなければならない。

　社内外のデータ／サービス連携では、API単位での管理が武器になってくるだろうと、福田氏は話す。

　「現状ではサービスチームごとに、自分たちが作ったAPIは見えるが、他のチームが作ったAPIが見えない。だが、他の部署が自分たちの作ろうとしているAPIと同様なものを既に作っているなら、自分たちもそれを使えばいいかもしれない。こうしたことを出発点として、APIのカタログ化から始め、社外の多様な人々が利用できる環境づくりを進めていきたい」と福田氏は話している。