KongHQ Summit Japan 2021

Solving Legacy
Issues
ONE API AT A TIME
Arshal Ameen
Nakajima Hiroki
Rakuten Group, Inc.

About Us
Arshal Ameen
Nakajima Hiroki
04
TABLE OF CONTENTS
06
03
Microservice Issues
Change is costly
API Gateway
Same tech new paradigm
Conclusion
Take-away
02
FINTECH LEGACY ISSUES
The undaunted ones 05
Benefits
From developer to business
manager
01

ABOUT US
01
The Incubators of
Technology

○ An application architect, responsible for designing
architecture of Fintech applications and infrastructure.
○ Technology Incubation Group
○ Build securely hyper connected self-reliant systems
Arshal Ameen

○ SIer、スタートアップ、起業、フリーランスなど多様なバックグラ
ウンドを経て楽天カードに⼊社。
○ レガシー/モダンアーキテクチャ、フロントからバックエンド、インフ
ラまで幅広く担当。
Nakajima Hiroki

現在ではインターネットバンキングやオンライン決済などを当たり前に利⽤しているが、
⾦融業界は古くからITによるオンライン化が進められてきた業界である。
そのため、古くから改修を重ねて稼働し続けているシステムも多くあり、それらの古いシステムを
修正・刷新するには⾮常に多くのコストと時間、そしてリスクが伴う状況になっているシステムが
多い。
古くからあるシステム、いわゆるレガシーシステムの課題はどのような部分にあるだろうか。
Fintech Legacy Issues

#1: Monolithic Architecture
01 修正や新規開発のたびにアプリケーション全体を
デプロイ、再起動する必要がある
03
バグや問題があればアプリケーション全体に影
響する
修正や新規開発のたびにアプリケーション全体の
影響調査、テストが発⽣する
02
04
DBに問題があればアプリケーション全体に影
響がある
1つの事象がアプリケーション全体に影響を及ぼす.

#2: Tight Coupling
01 修正や新規開発のたびに他のプロダクトに影響
がある
03
刷新するにも、1つのプロダクトを修正した際の
影響が⾮常に⼤き
1つのプロダクトに障害が発⽣すると、その他の正
常なプロダクトや、その先のプロダクトまで影響が
伝搬する
02
04
DBに問題があればアプリケーション全体に影
響がある
1つの事象が多くのプロダクトに影響を及ぼす

#3 - #5: No agility
03
アジリティ（機動性）の低下
ビジネスのスピードが速まっている中、顧客やビジネスパートナーの要求にすぐ
に対応することができないのはデメリットが⼤きい
05
メンテナンスコストの増加
修正・変更のたびに⼤規模な影響調査やテストが必要になり、プロダクトやビ
ジネスが成⻑するに従って正⽐例してメンテナンスコストの増加が懸念される
プロダクトの可⽤性・品質の低下
少しの変更がプロダクト・アプリケーション全体に影響を及ぼすため、可⽤性
や品質の低下に繋がる
04

And we all know solution for
legacy issues is
Microservice architecture but,

Microservices マイクロサービスアーキテクチャとは
旧来のモノリシックアーキテクチャと⽐べ、1つのシステムであって
も機能や⽬的という細かい単位で分割してサービスを提供する
アーキテクチャ
例) 受注管理システムの場合
- 顧客検索サービス
- 受注サービス
- 顧客応対サービス
このような単位で各機能をサービスとして独⽴させることが多い

Microservices マイクロサービスアーキテクチャは以下のメリットがある
1. 機能・⽬的ごとにアプリケーションが独⽴しているため、互
いに独⽴して修正、変更、デプロイが可能
→ 疎結合の解消につながる
2. DBやアプリケーションに障害があっても、機能単位で独
⽴しているため互いに影響しにくい（システム全体が利
⽤不可、となりにくい）
3. 個々のアプリケーションが独⽴しているため、技術的にロ
ックされにくい(柔軟な技術選定が可能)

#1: Routing
⼀⽅、マイクロサービスは複雑なアーキテクチャ
であり課題も多い
リリース時の切り替え
サービスやAPIリクエストが増えるため、ルーティ
ングが複雑になりやすい
適切なルーティングを⾏うために、Load
Balancerやリバースプロキシなどを複数配置し、
ルーティング設定をそれぞれのリクエスト先/元に合
わせて設定する必要がある。
Prod: A Prod: B Prod: C Prod: D Prod: E
Service: A Service: B Service: C
切替作業が複雑になる！

#2: Logging & Analytics
サービスが⼩さく・多くなり、サービスの通信が頻
繁に⾏われるためログ取得や解析が困難
API単位でのトラフィック分析などもサービス数
が増えると複雑になり制御が難しい
APIのリアルタイムアクセス率や負荷が⾒えない
各サービスごとにロギング⽤のミドルウェアなどを配
置、設定する必要がある。また、それらの設定を
変更すると各サービスに適⽤する必要があるなど、
煩雑になる。
Analytics: A Analytics : B Analytics : C
分析が難しい！

#3: Maintenance
サービス数が多くなるためリリースやバージョンアッ
プなどのメンテナンスが難しい
Repo: A Repo: B Repo: C
デプロイ・メンテナンスが大変！
サービス毎に異なるバーション管理、アップグレード、
アップデートの管理⼤変
ABテストやカナリアリリース
ブルーグリーンデプロイやアクティブスタンバイ構成

#4: Security
セキュアなネットワーク構築のためにセキュリティ要
件を定め、運⽤する際のコストが⾼い
Client: A Client: B Client: C
セキュリティの運用管理が大変！
各サービスごとに認証/認可の処理を実装し認
証キーなどを各サービスごとに適切に管理する必
要がある

#1: Routing
API/マイクロサービス間の通信を⼀元的に管理
できる
エンドポイントの追加/変更が容易
API間のコネクションが可視化され明確になる
Service : A Service : B Service : C

#2: Logging & Analytics
Analytics: A Analytics : B Analytics : C
API/マイクロサービス単位でロギング処理を適⽤
できる
どのAPIがどの程度利⽤されているかを分析す
ることが可能
APIごとに最適なロギング処理を個別に適⽤す
ることが可能

#3: Maintenance
Repo: A Repo: B Repo: C
API/マイクロサービス単位でリリース制御ができる
マイクロサービスの場合、サービス数が多くなる
とリリースフローが煩雑になりやすいが、API
Gatewayを利⽤することでカナリアリリースや
ABテストなどの制御がAPI単位で簡単に運⽤
可能
APIのバージョンごとの制御とバージョン⾃体の管
理

#4: Security
Client : A Client : B Client : C
API単位で認証/認可の処理を適⽤できる
API単位でのアクセス制御が可能
従来のネットワーク構成では困難だった、API単
位/機能単位での認証/認可を簡単に構築可
能 -> ゼロトラストネットワークの構築に役⽴つ
セキュリティリスクのあるルートだけを個別に停
⽌する / トラフィックの異常に多いAPIだけを個
別に流量制限するなどの運⽤が容易にできる

ネットワーク
アクセスの
信頼性
社内ネットワーク(上図の右側) 内のアクセスは基本
的に信頼されているため認証などは無い。または、
簡易的な認証程度のことが多い。
アクセスされる
場所/端末
⾃社ネットワーク(DMZ含む)内にある、事前に認可
された端末からのみアクセスが可能。
セキュリティ
対策の⽅法
基本的にはネットワークアクセスの⼊⼝への対策を
⾏う。
事前申請された端末やIPのホワイトリスト制限など
。
機能単位やアクセス元の単位で個別に異なる制御を
⾏うことは難しい。
#4: Security
従来のネットワークセキュリティ
（紳⼠協定的な信⽤）

ネットワーク
アクセスの
信頼性
外部/内部のネットワークに関わらず、全てのネッ
トワークは信頼できないものという前提で、基本的
に全てのアクセスは認証/認可の仕組みを経由して
アクセスを⾏う。
アクセスされ
る場所/端末
ネットワークアクセスの都度、認証/認可を⾏うた
め基本的にアクセス場所/端末に依存しない。
セキュリティ
対策の⽅法
ネットワークアクセスを動的に認証/認可し、その
都度アクセスの妥当性を判定するため、きめ細やか
な制御が可能。
機能単位・アクセス元ごとなどに個別に利⽤範囲を
フレキシブルに制御することができる。
#4: Security
ゼロトラストセキュリティ（信⽤しない、毎回認証）

Zero-trust-network with Kong HQ

v API間のコネクションが可視化され明確になる
v どのAPIがどこにあるかの把握が容易
v APIの再利⽤性が向上
v APIカタログの提供
v API仕様を⼀元管理できるため、調査やテストが
容易になる
v APIのモックテストが可能
v API GatewayのAPIモックを使⽤して対向APIの
実装を待たずにテストが可能
Benefits: Engineer

v APIをセキュアに外部公開しやすくなる
v ビジネスパートナーとの機会創出
v API単位での柔軟な制御が可能
v カナリアリリースやA/Bテストでプロ
ダクトの品質向上
v 耐障害性の向上
v 障害発⽣時の接続切り替えや切り戻し
が容易かつ早い
Benefits: Product Manager

v APIルーティングの追加・変更が容易
v APIのバージョンごとにエンドポイントを分け
て提供する
v ルーティングは変えずにAPI Gatewayの後続処
理だけを変えることが可能
v モノリシックアーキテクチャからマイクロサー
ビスなどのシステム移⾏時にも有効
Benefits: Architect

01 モノリシックアーキテクチャや密結合などのレガシー課題の解決のため、
マイクロサービスアーキテクチャへの移⾏が重要
03 マイクロサービスへのソリューションとしてAPI Gatewayが効果的
マイクロサービスアーキテクチャはメリットも多いが、デメリットも多い
Routing
Logging & Analytics
Maintenance
Security
02
04
Engineer / Product Manager / Architect のそれぞれに⼤きなメリット
がある

THANKS!
Do you have any questions?
Contact:
ameen.arshal@rakuten.com
hiroki.a.nakajima@rakuten.com

KongHQ Summit Japan 2021

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a KongHQ Summit Japan 2021

Similar a KongHQ Summit Japan 2021 (20)

Último

Último (7)

KongHQ Summit Japan 2021