こんにちは、KDDI アジャイル開発センターの佐々木です。

本日はKDDIマネージドポータルのアーキテクチャとパブリッククラウドに移行した経緯についてご説明いたします。本ブログは、アイレット株式会社様、グロース・アーキテクチャ＆チームス株式会社様（Graat）との合同開催ブログ記事の一環です。Graat様の記事はこちらからご確認いただけますので、併せてご覧ください。  

1. KDDI マネージドポータルとは？

KDDIが提供するKDDI Wide Area Virtual Swich (以下、WVS)、およびKDDI Wide Area Virtual Switch 2 といった閉域網サービスをご利用のお客様にご契約のネットワークの状態が確認できるポータルサイトです。

現時点では、いわゆるアンダーレイネットワークと言われる、足回り回線のみのご提供となっておりますが、KDDIが提供するSDWANサービスであるKDDI SD-Network Platformとの連携によるオーバーレイネットワークとの統合、さらにLAN保守契約のお客様には、お客様宅内のLAN情報との統合やAWS等のIaaS領域を、統合的に可視化するポータルとなることを目指しています。  

2.KDDIマネージドポータルのアーキテクチャ

KDDIマネージドポータルは、KDDIが提供するIaaSサービスであるKDDI Cloud Platform Service（以下、KCPS）とAmazon Web Service(以下、AWS)のマルチクラウドで構成されています。

お客様のリクエストは一度KCPSで受け、WVSのオプションメニューであるAWS Direct Connectを経由しAWSの環境にAPIをリクエストいたします。AWS側はALB、FargateとECS、NLB等を採用し、完全サーバレスで稼働しています。また、WVSの回線情報は社内システムで情報が管理されているため、ここでもDirect Connectを経由し対向システムへ接続・情報収集しレスポンスを返却いたします。

では、なぜこうしたKCPSとAWSのマルチクラウド構成となったのでしょうか？次章ではここについてご説明させていただきます。  

3.サービス・チームのスケーリングとマイクロサービスアーキテクチャ

KDDIマネージドポータルは、もともとKDDI ビジネスオンラインサポートという法人向けのポータルサイトの1機能でした。

実はこのサイトは、KDDI初のアジャイル開発案件として約6年前にリリースいたしました。弊社のお客様から頂いたフィードバックを元に、6年間常に機能追加を繰り返しています。また、当初はたった1チーム5名から始まったこのプロジェクトも、日本国内で５チーム、さらにはベトナムとのマルチサイト開発も行い、今では50名以上のメンバーが関わるプロジェクトへと成長しています。

その一方、絶えず開発し続けた膨大なアプリケーションのビルドは長時間化し、スローテスト問題に直面します。また、機能リリースにも各チームと同期を取りながら進めなくてはならず、月に1度のリリース以上のスピードが出ませんでした。これを脱却するには、モノリシックなアプリケーションから脱却し、チーム間の依存度を低減する必要があります。すなわちマイクロサービスアーキテクチャへの変更の必要性に迫られたのです。

また、同時に長期間開発を続けるには、利用しているOSやミドルウェアのバージョンアップも避けられません。機能が大きく成長したアプリケーションの土台のバージョンアップは大変な労力を伴う一方、ビジネスサイドからみると顧客価値を届けられずエンジニアのコストを浪費するように見えてしまいます。では、これを無くすためには、もしくは軽減するにはどうしたらよいのか。答えは自明で、マネージドサービスを活用したサーバレスアーキテクチャにより運用負荷を軽減させる、そのためにAWSで提供している各種機能群を活用することを決めました。  

4. これまでのナレッジとアセットを活用し更なるチーム・プロダクトの成長

KDDI ビジネスポータルは、大きくポータルと認証とが疎結合なアーキテクチャとなっており、認証はKDDI Business IDによるSSOを用いてログインいたします。

過去6年を振り返ると、大小含めポータルのリリース頻度が高く、その一方、可用性としては認証基盤に高い安定性を求められます。
そこで動的なポータルはマネージドサービスの恩恵を受けられるAWSに移行し、静的な認証基盤は稼働率の高いKCPSを継続利用することに決めました。

しかし、いざ「AWSを使う！」と決めてもこれまでKCPSを扱ってきたため、チーム内にはナレッジがなく、且つビッグバンリリースとなると相応にリスクを伴います。そこで、ポータル機能をサービス単位で切り出し、段階的にAWS移行する戦略（ストラングラーパターン）を採用いたしました。このようして、リスクを低減しつつチームでAWSを学習しながら進めました。

同時に考えるべきこととして、エンジニアにとって重要な案件であったとしてもこれを理由にビジネスを止めない、という点です。そこで、これまで培ってきたマルチサイトであるベトナムの開発チームにてビジネス要件を継続提供し続け、日本の開発チームはAWS移行に専任するという体制を敷くことで、この両輪を止めることなくリリースすることができました。

また、マイクロサービスアーキテクチャにおいては認証も肝になります。

もともと同一基盤で稼働していたKDDI ビジネスポータルは、KDDI Business IDで提供されるOpen ID Connect（以下、OIDC）という認証プロトコルによりSSOを行っておりました。分割対象のアプリケーションであるKDDI マネージドポータルの認証・認可もKDDI Business IDのOIDCを活用することにより、ブラウザのSSO、ならびにAPI認証を実現することでシームレスなユーザ体験を実現しています。

マイクロサービスアーキテクチャならびに認証アーキテクチャ検討にあたり、Graat 様に多大な協力をいただき実現しております、こちらのブログで詳細を解説いただいておりますので、併せてご活用ください。

そして忘れてはならない最後の砦、運用についても考えなくてはいけません。前述の通り、AWSのナレッジが少ない中で24時間365日の監視運用をしなくてはならないという課題に直面いたしました。そこで、KDDIグループのアセット活用としてアイレット様にご協力をいただきました。マネージドサービスの監視に加え、WVSとの接続点であるDirect Connectの監視もしていただき、クラウドとネットワーク、アプリケーションをワンストップの監視運用をご対応いただいております。現在、アイレット様でも事例公開の準備をしておりますので、こちらも併せてご確認お願いいたします(※)。

※4/3追記）アイレット様にて事例公開いただきましたので、こちらも併せてご確認お願いいたします。  

5. 最後に

巷ではクラウドを皮切りに、マイクロサービス、マネージドサービスなど様々なバズワードが飛び交っています。しかし重要なことは、自分が携わるプロダクトがどんな問題に直面していて、何を解決したいのかについて向き合うことです。そして、その先に初めてどうやって解決するのか、その方法論が存在します。

本投稿は、KDDIマネージドポータルのAWS移行に関してご説明いたしましたが、KDDI ビジネスオンラインサポートのポータル機能全体としてみたときは、まだ第一弾が終わったばかりです。
今後もAWS含め様々な改善を続け、より良いサービスをお客様にご提供いたします。