分散システムでは様々な原因によって処理が遅延する。止まらないシステムに欠かせないのがAPIのボトルネックの解消だ。サーキットブレーカーは復旧まで処理を肩代わりできるが、注意点もある。

 マイクロサービスアーキテクチャーでは、小さなサービスがAPI連携して大きなサービスを実現する。ただし1つのAPIに障害が発生すれば、連携するAPIに影響が生じる。どのように回避すればよいのだろうか。国内最大級のECサイトを運営する楽天の事例を基にコツを学ぼう。

APIを2種類に分けて管理

 楽天市場には多くのAPIが存在し、それぞれが連携しながらECサイトのサービスを実現している。止まらないシステムを実現するために楽天が力を入れているのがAPI連携時のボトルネック解消だ。楽天市場などのインフラを担当する楽天の橋詰尚毅クラウドプラットフォーム部スタックワイドリライアビリティ課SREグループマネージャーは「APIを大きく2種類に分けてボトルネックを解消している」と話す。

 具体的にはAPIをローレベルAPIとハイレベルAPIの親子に分け、依存関係の把握やボトルネック解消の優先度決定などに役立てている。ローレベルAPIはデータベースにアクセスする機能などを備える。一方のハイレベルAPIはローレベルAPIをいくつかまとめてデータを返すAPIである(図1)。

図1●APIを大きく2種類に分けてボトルネック解消
[画像のクリックで拡大表示]

 例えばハイレベルAPIにはアイテム管理APIが挙げられる。アイテム管理APIは、店舗情報や金額情報、在庫情報といった様々なデータを集めて表示しなければならない。店舗情報や金額情報を表示するAPIはローレベルAPIとして定義する。もし利用者のアイテムカゴに不具合が発生したら、ハイレベルAPIを特定し、その配下にあるローレベルAPIを修正していく。

サーキットブレーカーを設置

 データベースへの問い合わせ処理を担当するAPIでは、レスポンスの遅延が発生しやすい。そこで楽天ではローレベルAPIを中心に「サーキットブレーカー」を導入している(図2)。

図2●ローレベルAPIを中心にサーキットブレーカーを導入
[画像のクリックで拡大表示]

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら