全2180文字
PR
無料セミナー
接触確認アプリ、本当に使う?~公益のための個人データ活用とは 6/8 18時

分散システムでは様々な原因によって処理が遅延する。止まらないシステムに欠かせないのが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種類に分けてボトルネック解消
図1●APIを大きく2種類に分けてボトルネック解消
[画像のクリックで拡大表示]

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

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

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

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