現在JavaScriptの設定が無効になっています。このページを利用するにはJavaScriptの設定を有効にしてください。API運営の出水です。APIとは、APIやサーバーサイド技術にフォーカスした情報共有を定期的に行う勉強会/交流会イベントです。目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見を得たり技術交流の輪を広げたりすることのできる場を目指しています。API第1回のテーマは「APIの役割の多様化」です。海外進出によるリージョンの多様化や開発者向けAPIの公開に伴う利用者の多様化などの課題にどう対応しているか、といった話題を中心にAPIやサーバーサイド技術に関する様々なお話がありました。(@josolennoso)の計5名にご登壇いただきました。ヤフオク!アプリエンジニア一人目の登壇者はヤフオク!でiOSアプリ及びGo言語で書かれているアプリ用APIの開発を行っている山内。Backoffについて話しました。BreakerはバックエンドAPIのエラー頻度が事前に設定したしきい値を超えた場合に起動し、バックエンドAPIへのアクセスを遮断する仕組み。シンプルな機能ですが、この仕組みをアプリ用APIサーバーに導入することによって長期的な障害の起こっているバックエンドAPIサーバーへ無駄にアクセスしてタイムアウトするまで待ってしまう問題を防ぎ、システムの負荷を下げることができたとのこと。発動時に適切なアラートを上げることで、アプリ・アプリ用API・バックエンドAPIのどこで問題が起こっているのかを素早く的確に判断できるようになったとも話していました。訳される、バックエンドAPIがエラーとなった場合のリトライ間隔を指数関数的に長くしていく仕組み。Backoffを導入すればそのバランスをとることができるとして紹介していました。Backoffを使用したサーバー実装のデモも行われ、問題の発生後直ちに各機能が起動して無駄なAPIリクエストが起こらなくなることがよくわかりました。マイクロサービス化によってサーバー構成が多段となった上で結合度が下がると、通信先のサーバーの状態が通信元のサーバーから簡単にはわからなくなります。その課題を中央集権的にして結合度を上げてしまうことで解決するのではなく、シンプルなアルゴリズムの組み合わせを適切なサーバーに導入して切り抜けて行くこの方法なら言語やフレームワークにも依存せず導入できるので、これからより広く取り入れられていくのではないかと感じました。Engineer2人目の登壇者はMerpayでGo言語で構成される決済システムの開発を行っている佐野さん。Blogで紹介されていたアメリカ、イギリス、日本の三カ国でソースコードをフォークして別々に開発するようになったという件について、その経緯から現在の状況までをお話いただきました。メルカリのソースコードをフォークする前はアメリカと日本での展開で、サーバー・クライアントともに同じソースコードかつ巨大なモノリシックAPIを使用していたものの、だんだんアメリカのメルカリはコア機能から日本と異なるものになっていき、日本では共通するAPIを使用するメルカリ以外のサービスを開発するようになったため、フォークを検討するようになったとのことです。Assurance)もAPIの変更都度二カ国両方について行う必要があったことや、アメリカ現地での開発が増えたことでコミュニケーションが取りづらくなったことなど、様々な状況を鑑みてまずは2016年12月頃にクライアントサイドのソースコードをフォークすることになったと話されていました。その後メルカリはイギリスでもリリースされ、日本ではカウルやメゾンズ、メルカリチャンネル、メルカリNOWと様々なサービスを展開するようになった結果、2017年10月頃にAPIのソースコードをフォークすることとなります。このころはマイクロサービス化も進めており、運用がメインとなっていた日本と新規開発の多いイギリスではその方針も異なってきていたため、フォークすることによってより効率的に進められるようになるという点もメリットとして大きかったそうです。Gatewayの導入やより細かいマイクロサービス化を進めていくとのことでした。佐野さんのお話を聞いていて1番驚かされたのはその意思決定・実行のスピードです。たくさんの新しいサービスをものすごいスピードでリリースしながらも、適切なタイミングでシステムの見直しをかけ、都度あるべき姿に近づけようとする姿勢はとても参考になりました。エンジニア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テストのやり方について見直すいいきっかけとなりました。Gatewayなどの基盤システムを扱うチームのPMを行っている御代田さん。APIやSDKを社外の開発者に対して提供する上で出てきた課題や現在のバックエンドシステムの構成、API開発の体制の変化などについてお話いただきました。LINEでは通常のネイティブアプリの他にIn-appと呼ばれるLINEアプリの中で動くアプリも多く開発しているため、API開発ではそうした様々なタイプのアプリで使いやすいようにするという考慮が必要となってきます。そのため、初期のLINEではAPIを外部に公開するという部分まで十分に考慮されておらず、認証トークンの発行なども巨大なモノリシックサーバーの一部として提供されていたそうです。この頃も外部パートナーにAPIを提供することはあったものの、契約しているビジネスパートナーだったため、とてもいいとは言えないインターフェースでAPIの提供を行っていたということも実例を交えながらお話くださいました。Experience)をどうやって向上するかについて最も考えたと話しています。してもサービス利用者やビジネスパートナーを開発者よりも優先して考えてしまう傾向を変えるために、ここ数年は全てのAPIを外部に提供するという前提で書いているとのことでした。LINEは台湾やタイ、インドネシアでも人気があるため、アジア各国に開発拠点があり、日本国内でも東京だけでなく福岡と京都にも開発拠点を持っています。Relations)チームが積極的にそういったルールを統一するようになってきたそうです。御代田さんは他の登壇者と異なり、PMとしての視点からシステムの多様化に組織としてどう変化して対応していくかというお話を多くしてくださいました。APIを変化させていく上でどういう方針に立ってどんな組織体制を敷いていくのか、という点の重要性を強く感じられる内容でした。IDの管理開発をしている上野。認証の仕組みと特徴について話しました。従来よく使用されているパスワード認証ではパスワードを忘れてしまったり、使い回すことで外部サービスの脆弱性によって安全性が脅かされてしまったり、リスト型攻撃に弱かったりと、利便性と安全性に問題を抱えています。その問題を解決するために公開鍵暗号方式を使って所持認証や生体認証など様々な認証方法を選択可能な仕組みがFIDO認証とのこと。FIDO認証ではスマートフォンなどのローカルデバイス上で指紋などによる認証を行うことで所持と生体の両面から認証を行った上で、その認証結果に署名をつけてサーバーへ送信し、サーバー側での確認を可能にする仕組みです。サーバーへ送信される情報は認証の結果のみであるためパスワード自体をサーバーへ送信するパスワード認証と比べて漏洩の危険性が低く、本人性の確認にも2つの認証方式を組み合わせているため、1つだけの認証方式を採用している場合よりも安全性が高いそうです。Authenticationワーキンググループによってブラウザへの導入が進められており、FirefoxブラウザのNightlyなどですでに試す事ができるようになっているとのこと。これからはWebアプリケーションにもJavaScriptだけで簡単にFIDO認証を導入できる世界になっていくようです。ユーザーの認証はほとんどのサービスが必要とする機能でありながら、利便性と安全性の両方を備えた形での実装が難しいものだという印象があるのではないでしょうか。サービスを提供するデバイスも多様化して来ている昨今においては、FIDOのような標準規格の進化と浸透がより重要になっていくように感じました。APIでは「APIの役割の多様化」をテーマとして異なるサービスを提供する5名の方々にそれぞれの視点のお話をいただきました。運用・開発・テスト・セキュリティなど様々な視点におけるAPIのお話がありましたが、どの視点でもAPIを機能ごとに分割し、クライアント側の実装方法に依存しない汎用的な形にするという方向性は共通していたのではないかと思います。国際化対応やサードパーティへの展開、利用デバイスの増加によって生まれる多様性に対応しようとすると、どうしてもアプリケーションの仕様は複雑なものとなります。分離されたたくさんの機能を管理するための組織設計と具体的な事例をベースとした幅広い知見を集められたのではないかと思います。APIはサービスが実際に直面している課題やその課題への対応方法を通して、最新のAPIやサーバーサイド技術に関する知見を得られる場として開催していく予定です。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。