こんにちは。ヤフーで社内ソリューションアーキテクト（以下、社内SA）をしている小川です。
ヤフーには、大小さまざまなサービスが存在しています。今回は、それらのサービスをサポートしている、社内SAのお仕事をご紹介します。
ヤフーのプライベートクラウド環境
前提としてヤフーのサービスは、まずサービスレイヤーというのが上にあって、その下に共通のプラットフォーム、その下にインフラといったような水平分業の形になっています。
※ ヤフーのレイヤーイメージ
その中でも、プラットフォームレイヤーにはさまざまなクラウドサービスが存在しており、それらクラウドサービスを、AWSやGCPといったパブリッククラウドを利用するのではなく、独自のプライベートクラウド環境を構築および運用しているという点が、ヤフーの大きな特徴です。
一般的なソリューションアーキテクト
一般的に、AWSやGCPといったパブリッククラウドにおけるソリューションアーキテクトのお仕事は、お客様の課題に対して、技術の活用方法やベストプラクティスを紹介し、最適なアーキテクチャをご提案するものです。
パブリッククラウドを利用していれば、その製品のTAM（テクニカルアカウントマネージャー）等に相談できますが、前述しましたように、ヤフーでは社内向けに独自のプライベートクラウド環境を構築および運用しているため、相談先も社内の人間になります。
社内ソリューションアーキテクトが誕生した経緯
昨今のヤフーは、開発環境（= 社内プラットフォーム）のモダン化に取り込んでおり、世界の技術トレンドを見ながら、コンテナなどの新しいアーキテクチャの導入を進めています。
開発環境をモダン化するにあたって、既存の環境から新しい環境に移行をする必要があり、ヤフーのサービス担当者は、新しいアーキテクチャに合わせてシステムの設計を見直す必要がありました。
設計にあたって、サービス開発者から各プラットフォーム側に直接相談が来ていたのですが、プラットフォーム同士の連携や、推奨される構成等を認識した上で回答する必要があり、それらの情報を網羅的に把握した専門部隊（= 社内SA）が誕生し、新しいアーキテクチャの導入のサポートをしています。
社内ソリューションアーキテクトのお仕事
事例その1
例えば、以下のような相談が社内のユーザーから届いたとします。
新しくサービスを立ち上げたいと考えています。
最大500万ユーザーに対してリアルタイムにクイズを出題し、
クイズの正解数に応じて賞金を山分けするようなサービスです。
最大500万ユーザーが同時参加しても動作するようなコンピューティング基盤、
およびユーザーの回答データを保存するのに適切なデータストアを選定していただきたいです。
ピーク時のリクエスト数は、更新系で最大150万rpsほどが見込まれます。まずコンピューティング基盤ですが、選択肢としてはIaaS、PaaS、CaaSとあり、サービス開発者の運用コストを削減するためにも、できるだけPaaSもしくはCaaSで実現できないか検討します。
ヤフーの社内プラットフォームのPaaSはマルチテナント環境になっていて、大規模なサービスがPaaSに載ると、スパイクした際に他のサービスに影響を与えかねません。
最大150万rpsにもなるので、ヤフーの他のユーザーに不便をかける可能性を極力排除し、CaaSを採用とします。
次にデータストアですが、社内で提供しているデータストアとしては、RDBであればMySQLやOracle、NoSQLであればRedisやCassandraが利用可能となっています。
ヒアリングを進めたところ、このクイズの格納データは「列」と「行」の概念をもつ構造化データであり、反面、リアルタイムクイズなので500万ものユーザーに対し、95%以上で500msec以内にレスポンスを返さねばならないことがわかりました。
クイズの正誤データのように、データ同士のリレーショナルな処理（join）が必要ではないケースでは、RDBではなくNoSQLが向いており、データの読み書きの速度の速さが特徴である、Cassandraが適切であると判断し、賞金データはクイズの正誤データとjoinする必要があるためRDBが向いており、こちらはMySQLが適切であると判断し、システム構成を提案しました。
事例その2
次に、以下のような相談が社内のユーザーから届いたとします。
とあるサービスにおいて退会処理を実装したいと考えています。
ユーザーが退会すると格納されているデータの削除を実行しますが、
この削除処理に時間がかかることが予想され、最大5分程度を想定しています。
時間のかかる処理を実現したい場合、推奨される構成等があれば教えてください。本件では、データの削除に時間がかかるため、その部分は非同期処理が望ましいと考えられます。 非同期処理の場合、社内プラットフォームの一つとして提供しているメッセージキュー（MQ）の利用が推奨されます。
メッセージキューではメッセージの送信側（Producer）と受信側（Consumer）とを定義しており、ProducerとConsumerは互いを意識しない疎結合な構造になっているため、非同期にメッセージを受け渡したり、容易にスケールアウトできるのが特徴です。
ちなみに上述しましたメッセージキューは、Yahoo! Inc.（現Verizon Media）が設計および開発しOSSとして公開したもので、現在はApache Software Foundationに移管されています。
■ Apache Pulsar
https://pulsar.apache.org
よろしければこちらの記事もご覧ください。
本件の場合は、以下のような流れで処理をします。
- ユーザーがサービスを退会する
- 退会APIがたたかれ、データを削除するためのキューをpublishする
- Consumerがキューをsubscribeし、削除APIをたたく（この処理に最大5分程度を要します）
退会APIや削除APIは、リクエスト数やペイロードサイズが小さいためPaaSを採用します。
次にConsumerをどのコンピューティング基盤で実現するかですが、本件のようにイベントドリブンな処理の場合は、こちらも社内プラットフォームの一つとして提供しているFaaS（Function as a Service）の利用を推奨しています。
サービス開発者はFaaSにアクションとイベントを登録することで、登録したイベントの発生をトリガーとしてアクションを実行でき、アクションの実行はFaaS上のコンテナで実行されるため、サービス開発者はサーバの構築および運用をすることなく、イベントドリブンなアクションを作成することができます。
事例その3
次に、以下のような相談が社内のユーザーから届いたとします。
現在、社内で公開されているAPIを、社外にも公開したいです。
具体的には、以下を満たすAPIの構成で悩んでいます。
1. 社外からは、クライアント端末 (スマートフォンアプリ内) から直接APIにリクエストされる
2. 社内からは、社内の別サービスからAPIにリクエストされ、APIには社内認証によるアクセス制御をかける
推奨される認証方式や、どの部分で認証をかけるべきか等、教えてください。ヤフーには「Yahoo!デベロッパーネットワーク」という、クリエイターの皆さんとYahoo! JAPANの技術をつなげるポータルサイトがあり、その中で様々なWebAPIを公開しています。
本件は、すでに社内で利用されているAPIを、Yahoo!デベロッパーネットワークに公開したいというもので、その際の認証や構成のベストプラクティスを知りたいという相談内容になります。
■ Yahoo!デベロッパーネットワーク
https://developer.yahoo.co.jp/
ヤフーでは、社外からの入り口としてリバースプロキシを社内プラットフォームの一つとして提供しており、ヤフーのユーザーからリクエストを受け付けて、指定のサービスのバックエンドサーバ（オリジンサーバ）へリクエストを転送します。
その際、転送時に様々な用途に合わせた付加処理を行うことができ、特定のアクセストークンが含まれるリクエストのみ、リクエストの転送がされるように制御することが可能（特定のWebAPIを特定のクライアント端末からのみ利用可能にする、ような活用が可能）です。
ヤフーでは「Athenz」と呼ばれるRBAC（ロールベースアクセス制御）を用いて社内プラットフォーム間のアクセス制御をしており、本件における「社内で公開されているAPI」には社内用の認証（Athenz）がかかっているため、上述しましたリバースプロキシにおける認証とは分ける必要があります。
以上から、下記のいずれかの方針で要件を満たすことができると判断しました。
- アクセスを社内外で判定して、社外からのアクセスは上記リバースプロキシで認証する
- エントリーポイントを社内外で分けて、社外に公開するAPIは上記リバースプロキシで認証する
ちなみにAthenzは、Yahoo! Inc.（現Verizon Media）が設計および開発しOSSとして公開したもので、現在はYahoo! JAPANがVerizon Mediaと協業の上、OSSへの貢献をしています。
■ Athenz
https://www.athenz.io
社内ソリューションアーキテクトの役割と今後の展望
このように社内SAがサポートに入ることで、正しいアーキテクチャをサービス開発者にインプットすることができ、プラットフォームのリソースを最大限活用することで、ヤフーのプライベートクラウド環境の安定稼働にもつながっています。
ヤフーではコンピューティングやデータストアだけでなく、100を超えるさまざまな社内プラットフォームを提供しており、それぞれが機能等のアップデートしているため、日々プラットフォーム側と連携し、正しい情報のキャッチアップに努めています。例にあげたような、サービス開発者からのアーキテクト相談を日々受けている傍ら、よくある相談内容や推奨される構成等を、「構成例」や「デザインパターン」といった形のドキュメントとして社内に公開しています。
※ 社内で公開しているドキュメントサイト
将来的には、社内のドキュメントを拡充させ、正しいアーキテクチャはドキュメントに全て書いてあるという状態にすることで、社内SAへの相談にかかる工数を削減し、ヤフーのサービス開発者が開発だけに集中できる環境を提供することができればと考えています。
おわりに
いかがでしたか？ ヤフーのサービスを支える社内ソリューションアーキテクトのお仕事をご紹介しました。
ヤフーのようなサービス規模で、独自のプライベートクラウド環境を構築および運用している企業は少なく、それらを支える技術基盤を常にアップデートし続けるという、ここでしか身につけられないスキルを身につけることができます。ヤフーでのお仕事に、少しでも興味を持たれた方がいましたら幸いです。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
- 小川 佳亮
- 社内ソリューションアーキテクト
