ヨドバシAPIのアーキテクチャが目指すものとは?〜APIエコノミー、ゼロトラスト、開発生産性向上への取り組み
2023年10月27日、クリエーションライン株式会社は「Actionable Insights Day 2023」を開催した。特別講演では、クリエーションラインが開発を支援する株式会社ヨドバシカメラによる、APIを軸にしたIT戦略と、そのアーキテクチャについての解説が行われた。本記事では、セッションの模様をレポートする。
⚫︎クリエーションライン株式会社の特別講演についてはコチラ
https://thinkit.co.jp/article/22595
APIを介して繋がるヨドバシのエコシステム
セッションの冒頭では、株式会社ヨドバシカメラ 代表取締役社長 藤沢 和則氏より、ヨドバシカメラのビジネスの現状と、目指す世界について説明があった。
ヨドバシカメラのビジネスにおけるネット通販の売上は、今や総売上の3割を占めている。その比率は毎年上がっており、今後は5割を目指しているという。店頭でのビジネスだけでなく、裏側を支えるITの重要性が増す中で、ヨドバシカメラはIT面でも様々な取り組みを行っている。過去30年間、インターネットの出現やスマートフォンの登場といった変化に対し、いち早くECサイトを立ち上げるなど、ヨドバシカメラはいち早く時代の変化に対応してきた。そして今、2040年まで第一線で活用できる、新たなアーキテクチャを設計するプロジェクトが動いている。それがプロジェクト2040だ。
プロジェクト2040が目指すのは、店舗、物流、決済などヨドバシカメラのバックエンドをサービスとして提供し、企業間取引のプラットフォームとして活用する構想だ。その実現の要となるのが、ヨドバシカメラが開発を進めているヨドバシAPIだ。
藤沢氏は「企業がシームレスにお互いのリソースを共有しあって、新たなサービスの創出と社会への貢献を行えるようになることが、プロジェクト2040の目標です」と話した。
店員に相談するかのような親しみやすいAPI体験を目指す
続いて、株式会社ヨドバシリテイルデザイン サービスデプロイメント事業部 事業部長 戸田 宏司氏が、ヨドバシAPIのアーキテクチャについて解説した。
ヨドバシカメラは、商品案内からレジでの購入まで、あらゆる顧客接点で、顧客への感謝と丁寧な接客を心がけている。APIもまたシステムにおける顧客接点として、この接客精神を実現しなければならないと、戸田氏は言う。ドメイン駆動設計のエリック・エヴァンスの言葉も引用しながら、戸田氏はAPI設計における指針を「お客様にとって快適で便利な接点を提供し続けるエンドレスストーリー」だと定義する。そしてドメイン駆動設計に基づき、システムと顧客との接点をビジネスドメインに分割し、企業間連携のプラットフォームを担うWEB APIとして公開することを目指している。そして、それぞれのドメインで顧客の立場に立って、必要なリソースに対するアクションをAPIで提供していくという。
APIは標準的なREST APIとして提供される。しかし、いわゆるCRUD(永続性を備えたソフトウェアが持つ、生成・読み取り・更新・削除の4つの機能)をそのまま提供するのでは、ユーザーフレンドリーではない場面もある。そこで、ヨドバシAPIではCQRS(コマンドとクエリの責務分離)パターンを採用することで、様々なユースケースに合わせたクエリを提供する。戸田氏は「素っ気ないREST APIにヨドバシ店員の接客力を取り入れたいのです。ヨドバシの店員に相談するときのように、お客様のご要望を推察し、適切なタイミングでご案内する。そんな感覚で使えるAPIを目指しています」と説明する。
例えば、利用者が商品を購入すると、コマンドのドメインモデルにデータがストアされる。その後、利用者への提案にあたるクエリモデルが生成される。これを適切なタイミングで利用者に提示することで、ヨドバシ店員に相談するかのように、商品のレコメンドができる。このような接客体験を、API上でも実現したいと、戸田氏は言う。
ヨドバシAPIは、顧客をAPIのリソースオーナーと位置づけ、そのリソースを守るためにNIST SP800-207に準拠したゼロトラスト・アーキテクチャを採用している。ゼロトラストアーキテクチャーには7つの基本方針があるが、戸田氏によれば、これらは以下の3点に要約できるという。
- リソースは必要に応じてアクセス可能であること
- アクセスは動的に検証可能であること
- セキュリティ観点での監視・測定が行われること
アクセス元であるSubjectがリソースに問い合わせをすると、ポリシー決定ポイント(PDP)と連動してポリシー実施ポイント(PEP)によって検証され、合格するとトラストゾーンに到達できる。この検証はプロセスは全て監視され、APIのすべてのエンドポイントに適用される。さらに、境界防御モデルの併用も行い、リソースの機密レベルに応じた配置を考慮しているという。
認証については、NIST SP800-63BにおけるAAL3準拠を目指している。つまり多要素認証、ハードウェアベースの暗号鍵の併用だ。ただし、最新の認証の仕組みであるPasskeysでは、利便性を重視してクラウドによる暗号鍵の連携を可能にしている。そのため、本来のAAL3と比べて保護レベルがやや低下する懸念がある。そこでヨドバシAPIでは、Open ID ConnectのCONNECTのDynamic Client Registration技術を採用し、クライアント認証にprivate_key_jwtを使用している。この秘密鍵はハードウェア内で保護されており、クライアント認証とPass Key認証を組み合わせることで、間接的にセキュアなハードウェアに保存された秘密鍵に署名する。こうすることで、利便性を確保しつつ、AAL3に迫る保護レベルを達成したいと戸田氏は言う。またクライアント認証の副産物として、このクライアントはCIBA(Client Initiated Backchannel Authentication)におけるConsumption Deviceとして利用可能になるという。
認可については、一般的な仕様であるOAuth 2.0を採用している。認可プロセスでは、OP(認可プロバイダ)から認可コードが発行され、この認可コードと引き換えにアクセストークンを取得する。API呼び出し時には、このアクセストークンをサーバーに提示し、リソースサーバー側でトークンの検証を行い、API利用を許可する。顧客のリソースを保護する上で課題となるのが、アクセストークンのセキュリティ対策だ。そこで、以下の対策を講じている。
1つ目はアクセストークンの有効期限を短く設定すること、2つ目はアクセストークンだけでは利用できないようにすることだ。後者を実現するための仕組みが所持証明(Proof of Possession)だ。具体的には、トークンエンドポイントにアクセストークンを要求する際、DPOP(Demonstrating Proof of Possession)の公開鍵をOP側に登録する。APIを呼び出す際には、DPOPの秘密鍵による証明と、既に取得したアクセストークンを組み合わせて提示する。DPOPには、同じ秘密鍵による署名が再利用できない仕組みがあり、署名が盗まれた場合でもリプレイ攻撃ができないため、リソースサーバー側で不正が検知可能だ。これにより、アクセストークンが奪われても再利用できないようにしている。
続けて、戸田氏はヨドバシAPIの開発を円滑に進めるための取り組みを紹介した。
第一の取り組みとして、APIの標準規約の策定が挙げられる。例えば、レスポンス可能なリソースが存在しない場合、ある設計者はレスポンスコード200(正常)を返し、レコードの件数を0件とする設計を行うかもしれない。一方で、ある設計者はリソースが存在しないためにレスポンスコード404(Not Found)を返す設計を行うかもしれない。サービス間の連携では、このような細かい仕様の違いも問題になるかもしれない。そこで、これらの挙動を事前に定義することで、議論の必要性を減らし、効果的に開発を進めることができるようにしている。
第二に、APIのデザインツールの導入がある。API標準規約があっても、ルールを100%正確に実施することは難しい。そこで、デザインツールによる開発ガイドの提供や、辞書機能による定義済み項目名の再利用、自動チェックを行うことで、開発の高速化と品質の安定化を実現している。
第三には、APIカタログの導入が挙げられる。これはステークホルダーとの合意形成に重要であり、開発者とステークホルダーが同じ目標に向かって作業できるようにするものだ。また、異なるドメインの開発チームがこのカタログを参照することで、迅速な開発が可能となる。
第四には、APIのジェネレーターの導入がある。これは、APIのデザインから始まり、ソースコード生成に至るまでのプロセスを自動化するものだ。
最後に「自動ゼロトラスト化の実現」が挙げられる。これは、APIサーバーのデプロイ時にNIST SP800-207に基づくポリシー実施ポイント(PEP)を自動的に付与する仕組みであり、セキュリティの強化に貢献している。これらの取り組みを通じて、API開発における生産性とセキュリティの向上を図っている。
最後に、戸田氏はヨドバシグループの開発体制をアピールした。プライベートクラウドからアーキテクチャ設計、認証・認可の仕組みなどをフルスクラッチで開発するなど、エンジニアにとってはとても面白い環境だと戸田氏は言う。また、ドメインエキスパートとして、経営層も開発者と同じ目線で開発に取り組んでいるので、多くの企業が悩まされる複雑な承認フローとも無縁だと強調した。戸田氏は「ヨドバシのビジネスを一緒に創造する仲間を募集しています。ぜひヨドバシドットジョブズへアクセスしてください」と述べ、講演を終えた。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Keycloakと認可プロダクトを利用したマイクロサービスにおける認証認可の実現
- FAPIとKeycloakの概要
- Keycloakの最前線を体感できるイベント「Keyconf 23」レポート
- コンテナ上のマイクロサービスの認証強化 ~IstioとKeycloak~
- Oracle Cloud Hangout Cafe Season4 #4「マイクロサービスの認証・認可とJWT」(2021年7月7日開催)
- AI駆動開発とエンタープライズChatGPTが企業にもたらす可能性 〜クリエーションラインの生成AIへの挑戦
- KeycloakによるAPIセキュリティの基本
- APIセキュリティのハードニング
- FAPI 1.0に準拠したクライアントアプリケーションと リソースサーバの作り方
- Keycloakのインストールと構築例