こんにちは! Bonfire API運営の出水です。
2月1日(木)に弊社のコワーキングスペースLODGEでBonfire API #1を開催しました!
Bonfire APIとは、APIやサーバーサイド技術にフォーカスした情報共有を定期的に行う勉強会/交流会イベントです。
目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見を得たり技術交流の輪を広げたりすることのできる場を目指しています。
テーマ「APIの役割の多様化」
Bonfire API第1回のテーマは「APIの役割の多様化」です。
海外進出によるリージョンの多様化や開発者向けAPIの公開に伴う利用者の多様化などの課題にどう対応しているか、といった話題を中心にAPIやサーバーサイド技術に関する様々なお話がありました。
ヤフーからヤフオク!アプリエンジニアの山内とIDソリューション統括本部 サーバーサイドエンジニアの上野、ゲストスピーカーとしてMerPay Server Side Principal Engineerの佐野さん (@kazegusuri)、株式会社Gunosy 新規事業開発室 エンジニアの高橋さん (@__timakin__)、LINE株式会社デベロッパープロダクトチームの御代田さん (@josolennoso)の計5名にご登壇いただきました。
1. APIのリトライ処理
山内 晨吾
ヤフー株式会社 ヤフオク!アプリエンジニア
一人目の登壇者はヤフオク!でiOSアプリ及びGo言語で書かれているアプリ用APIの開発を行っている山内。
ヤフオク!のマイクロサービス化を中心とする大規模なシステムリニューアルの中でアプリ用APIとヤフオク!の本体機能APIを疎結合にするために導入している2つのアルゴリズム、Circuit BreakerとExponential Backoffについて話しました。
Circuit BreakerはバックエンドAPIのエラー頻度が事前に設定したしきい値を超えた場合に起動し、バックエンドAPIへのアクセスを遮断する仕組み。
シンプルな機能ですが、この仕組みをアプリ用APIサーバーに導入することによって長期的な障害の起こっているバックエンドAPIサーバーへ無駄にアクセスしてタイムアウトするまで待ってしまう問題を防ぎ、システムの負荷を下げることができたとのこと。
また、発動時に適切なアラートを上げることで、アプリ・アプリ用API・バックエンドAPIのどこで問題が起こっているのかを素早く的確に判断できるようになったとも話していました。
次に、Exponential Backoffは「指数関数的後退」と訳される、バックエンドAPIがエラーとなった場合のリトライ間隔を指数関数的に長くしていく仕組み。
Circuit Breakerの導入だけではしきい値を大きくしすぎるとリトライによるシステム負荷が残り、小さくしすぎると何度かリトライすることで通せたはずの処理が失敗してしまいますが、Exponential Backoffを導入すればそのバランスをとることができるとして紹介していました。
発表内ではCircuit BreakerとExponential Backoffを使用したサーバー実装のデモも行われ、問題の発生後直ちに各機能が起動して無駄なAPIリクエストが起こらなくなることがよくわかりました。
マイクロサービス化によってサーバー構成が多段となった上で結合度が下がると、通信先のサーバーの状態が通信元のサーバーから簡単にはわからなくなります。
その課題を中央集権的にして結合度を上げてしまうことで解決するのではなく、シンプルなアルゴリズムの組み合わせを適切なサーバーに導入して切り抜けて行くこの方法なら言語やフレームワークにも依存せず導入できるので、これからより広く取り入れられていくのではないかと感じました。
2. Real World Mercari API Architecture
佐野 正浩 (@kazegusuri)
MerPay Server Side Principal Engineer
2人目の登壇者はMerpayでGo言語で構成される決済システムの開発を行っている佐野さん。
メルカリのEngineering Blogで紹介されていたアメリカ、イギリス、日本の三カ国でソースコードをフォークして別々に開発するようになったという件について、その経緯から現在の状況までをお話いただきました。
メルカリのソースコードをフォークする前はアメリカと日本での展開で、サーバー・クライアントともに同じソースコードかつ巨大なモノリシックAPIを使用していたものの、だんだんアメリカのメルカリはコア機能から日本と異なるものになっていき、日本では共通するAPIを使用するメルカリ以外のサービスを開発するようになったため、フォークを検討するようになったとのことです。
また、サービスの品質を保つために行っていたテスト作業(QA: Quality Assurance)もAPIの変更都度二カ国両方について行う必要があったことや、アメリカ現地での開発が増えたことでコミュニケーションが取りづらくなったことなど、様々な状況を鑑みてまずは2016年12月頃にクライアントサイドのソースコードをフォークすることになったと話されていました。
その後メルカリはイギリスでもリリースされ、日本ではカウルやメゾンズ、メルカリチャンネル、メルカリNOWと様々なサービスを展開するようになった結果、2017年10月頃にAPIのソースコードをフォークすることとなります。
このころはマイクロサービス化も進めており、運用がメインとなっていた日本と新規開発の多いイギリスではその方針も異なってきていたため、フォークすることによってより効率的に進められるようになるという点もメリットとして大きかったそうです。
今後は日本のサービスが増えたことで、それらをモノリシックなAPI機能で提供することが難しくなってきたため、日本でのサービス専用のAPI Gatewayの導入やより細かいマイクロサービス化を進めていくとのことでした。
佐野さんのお話を聞いていて1番驚かされたのはその意思決定・実行のスピードです。
たくさんの新しいサービスをものすごいスピードでリリースしながらも、適切なタイミングでシステムの見直しをかけ、都度あるべき姿に近づけようとする姿勢はとても参考になりました。
3. A/Bテスト機構の実装と、それがもたらす大胆な開発体制とゆるやかなアプリ体験の変化
高橋 誠二 (@__timakin__)
株式会社Gunosy 新規事業開発室 エンジニア
3人目の登壇者はGunosyでLUCRAという女性向けメディアサービスのiOSアプリ及びGo言語で書かれているサーバーの開発を行っている高橋さん。
LUCRAでは状況に応じた大胆な開発を行うために日々多くのA/Bテストを行っているとのことで、その仕組みを提供する基盤APIやA/Bテストの実例についてお話いただきました。
A/Bテストはユーザーの一部を抽出して施策の妥当性やユーザーの行動に対する仮説の検証を行うために使用されますが、そのA/Bテストをたくさん行う場合、1人のユーザーに対して相互に影響し合うようなテストを同時に行ってしまうと適切な結果を得られません。
LUCRAではAllocation、Experiment、Variantというテスト対象ユーザをグルーピングする3つの枠組みを設定することで適切なA/Bテストを行えるようにする基盤APIを構築・運用しているとのことで、その構造と効果について説明してくださいました。
まず、Allocationは複数のA/Bテストをグルーピングし、ユーザ全体に対する各A/Bテストグループの割当率を指定するとともに、同じグループに属するテストが同じユーザーに重複して割り当てられることがないように管理するための枠組みです。
次に、ExperimentはAllocationに属するA/Bテストそのもの、VariantはExperimentに属するA/Bテストのテストケースに当たります。
A/Bテストの管理にこうした階層構造を与えて包含・排他の関係を明確化できるようにすることで、安全にA/Bテストを行うための仕組みを整えることができたそうです。
また、本番リリースの前にA/Bテストを行うことで段階的リリースと同じような効果もあり、ユーザーに本当に求められる機能をより安全に提供できるようになったともお話されていました。
高橋さんも冒頭で言われていたとおり、今や導入していないサービスはほとんどないA/Bテストですが、たくさんのA/Bテストを日々行っていく上ではまだまだ多くの課題があります。
基盤の仕組みを自ら実装することでその課題に対応したという高橋さんのお話はとても刺激的で、A/Bテストのやり方について見直すいいきっかけとなりました。
4. LINEにおけるデベロッパープロダクトシステムのマイクロサービス化
御代田 亮平 (@josolennoso)
LINE株式会社デベロッパープロダクトチーム
4人目の登壇者はLINEでログイン機能や認証トークン、SDK、API Gatewayなどの基盤システムを扱うチームのPMを行っている御代田さん。
APIやSDKを社外の開発者に対して提供する上で出てきた課題や現在のバックエンドシステムの構成、API開発の体制の変化などについてお話いただきました。
LINEでは通常のネイティブアプリの他にIn-appと呼ばれるLINEアプリの中で動くアプリも多く開発しているため、API開発ではそうした様々なタイプのアプリで使いやすいようにするという考慮が必要となってきます。
そのため、初期のLINEではAPIを外部に公開するという部分まで十分に考慮されておらず、認証トークンの発行なども巨大なモノリシックサーバーの一部として提供されていたそうです。
また、この頃も外部パートナーにAPIを提供することはあったものの、契約しているビジネスパートナーだったため、とてもいいとは言えないインターフェースでAPIの提供を行っていたということも実例を交えながらお話くださいました。
そうした状況からサードパーティの開発者へ本格的にAPIの提供を始めるにあたって、御代田さんはUX (User Experience)だけでなくDX (Developer Experience)をどうやって向上するかについて最も考えたと話しています。
どうしてもサービス利用者やビジネスパートナーを開発者よりも優先して考えてしまう傾向を変えるために、ここ数年は全てのAPIを外部に提供するという前提で書いているとのことでした。
また、LINEは台湾やタイ、インドネシアでも人気があるため、アジア各国に開発拠点があり、日本国内でも東京だけでなく福岡と京都にも開発拠点を持っています。
そのままだと各開発チームがそれぞれのルールでAPIを実装して統一されない状況となっていたため、CTO直下のSDKチームやDevRel (Developer Relations)チームが積極的にそういったルールを統一するようになってきたそうです。
御代田さんは他の登壇者と異なり、PMとしての視点からシステムの多様化に組織としてどう変化して対応していくかというお話を多くしてくださいました。
APIを変化させていく上でどういう方針に立ってどんな組織体制を敷いていくのか、という点の重要性を強く感じられる内容でした。
5. 生体認証のAPI化
上野 博司
ヤフー株式会社 IDソリューション本部 サーバーサイドエンジニア
最後の登壇者はYahoo! JAPAN IDの管理開発をしている上野。
ユーザーセキュリティ向上のために参画しているFIDO Allianceの活動に関連して、FIDO (Fast Identity Online) 認証の仕組みと特徴について話しました。
従来よく使用されているパスワード認証ではパスワードを忘れてしまったり、使い回すことで外部サービスの脆弱性によって安全性が脅かされてしまったり、リスト型攻撃に弱かったりと、利便性と安全性に問題を抱えています。
その問題を解決するために公開鍵暗号方式を使って所持認証や生体認証など様々な認証方法を選択可能な仕組みがFIDO認証とのこと。
FIDO認証ではスマートフォンなどのローカルデバイス上で指紋などによる認証を行うことで所持と生体の両面から認証を行った上で、その認証結果に署名をつけてサーバーへ送信し、サーバー側での確認を可能にする仕組みです。
サーバーへ送信される情報は認証の結果のみであるためパスワード自体をサーバーへ送信するパスワード認証と比べて漏洩の危険性が低く、本人性の確認にも2つの認証方式を組み合わせているため、1つだけの認証方式を採用している場合よりも安全性が高いそうです。
また、FIDO認証は現在W3CでWeb Authenticationワーキンググループによってブラウザへの導入が進められており、FirefoxブラウザのNightlyなどですでに試す事ができるようになっているとのこと。
これからはWebアプリケーションにもJavaScriptだけで簡単にFIDO認証を導入できる世界になっていくようです。
ユーザーの認証はほとんどのサービスが必要とする機能でありながら、利便性と安全性の両方を備えた形での実装が難しいものだという印象があるのではないでしょうか。
特にサービスを提供するデバイスも多様化して来ている昨今においては、FIDOのような標準規格の進化と浸透がより重要になっていくように感じました。
まとめ
第1回のBonfire APIでは「APIの役割の多様化」をテーマとして異なるサービスを提供する5名の方々にそれぞれの視点のお話をいただきました。
運用・開発・テスト・セキュリティなど様々な視点におけるAPIのお話がありましたが、どの視点でもAPIを機能ごとに分割し、クライアント側の実装方法に依存しない汎用的な形にするという方向性は共通していたのではないかと思います。
国際化対応やサードパーティへの展開、利用デバイスの増加によって生まれる多様性に対応しようとすると、どうしてもアプリケーションの仕様は複雑なものとなります。
その課題に対して今回のBonfire APIでは
- まとまっていたサーバー側の複雑さを下げるためのマイクロサービス化
- A/Bテストや認証といった複雑な機能の分離や外部化
- バックエンドとの疎結合性を保つためのリトライ設計
- 分離されたたくさんの機能を管理するための組織設計
と具体的な事例をベースとした幅広い知見を集められたのではないかと思います。
今後もBonfire APIはサービスが実際に直面している課題やその課題への対応方法を通して、最新のAPIやサーバーサイド技術に関する知見を得られる場として開催していく予定です。
Bonfireの開催はconnpassで告知しますので、ぜひメンバーになって次回以降のイベントにご参加ください!
photo credit : 都筑 一希
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
