目次
- はじめに
- SDP開発とは
- SDP開発とは
- SSS/SDPフレームワーク
- ICGW-SDP基盤
- 全体構成
- CI/CD
- ICGWの可視化
- APIリクエスト数
- リソース利用状況
- おわりに
はじめに
こんにちは、5G & IoT部/IoTサービス部門のIoT Connect Gateway (ICGW)サービス開発チームの岩田です。 我々のチームでは2021年度下期に私の主導のもと、ICGWのSDP開発というものを行い、Smart Data Platform (SDPF)ポータル対応およびSDPF上で展開している他のサービスとの自動連携を実現しました。 本記事ではこのICGWのSDP開発に焦点を当てて、開発背景や全体構成ならびにCI/CDを紹介します。 また、ICGWの可視化関連の情報も合わせて掲載しますので、今後の開発のご参考になれば幸いです。
ICGWのサービス自体やユースケースに関して、過去の記事で紹介していますのでご参照ください。
IoT Connect Gateway を使ってみた 第1回 〜ICGWのご紹介〜
IoT Connect Gateway を使ってみた 第3回 〜観葉植物育成状況の可視化〜
SDP開発とは
サービス開発における背景
従来のNTT Comのサービスでは、サービスのコアとなる技術要素のみが開発の対象となっており、そのサービスをユーザに届けて対価を得る部分はプロセス整備として扱われ開発の主な対象ではありませんでした。
しかし、近年サービスのオンライン化やセルフマネジメント化が強く推進される中で開発しなければならない範囲は拡大し続けています。 ユーザがサービスのセルフマネジメントを行うためのAPI/GUI、それらを提供するための認証/権限管理機構、ユーザのサービス利用状況の管理/システム化などが必要となってきます。 また、サービスへの申込みや料金計算をオンライン化/自動化したい場合はさらに開発対象の範囲は広がります。
SSS/SDPフレームワーク
SDPFポータルで展開するサービスを開発する上で欠かせないSSS/SDPというフレームワークを紹介します。 SSSは「Shared Support Service」、SDPは「Service Delivery Platform」の略語でNTT Comの用語です。
このフレームワークにおいて、各SDPはサービスのコアになる技術とそれをユーザが利用するためのIF（GUI/API）の開発に集中し、SSSがその土台となる契約の申し込み、契約管理、認証の基盤やユーザ権限管理、料金計算等を一手に担います。 SSS/SDPフレームワークに則り開発を進めることで、それぞれの役割を明確に分担して重複開発を避けられるというアイディアになっています。
SSSや他のSDPとやり取りするための統一的な規格にサービス仕様を合わせることを我々のチームではSDP開発と呼んでいます。 SDP開発によって我々のICGWにおいても、サービス運用やユーザ利便性の面において多くのメリットをもたらしました。
図3はSDP開発によって新規に実装されたGUIのサンプルです。 ユーザが設定を投入するためのページだけでなく、利用状況を視覚的に表現したページを提供することによって利便性向上を図っています。
ICGW-SDP基盤
ICGW全体構成
ICGWは大きく分けてICGW-core基盤とICGW-SDP基盤の2つからなっています。 ICGW-core基盤はSDP開発前から存在しているもので、デバイスからのデータが流れるデータプレーンやSO APIを提供しています。 ICGW-SDP基盤はSDP開発時に新設されたもので、ユーザが設定を投入するためのGUIやAPI、SSSや他SDPと連携するためのAPIなどを提供しています。
もともとICGWはSDPに対応しない形でサービスリリースしたため、サービスのコアとなる部分はすでに出来ていました。 そのため、ICGW-SDP基盤では特にユーザIFに注力する形での開発となりました。 ICGW-SDP基盤のAPIは裏側でSO APIをコールしており、基本的にユーザのリクエストをそのまま裏へ流し、必要に応じてSDPの規格を満たすようにリクエスト内容を加工できるような設計になっています。
実際にこのような二段構成で運用してみたところ、いくつかのメリットがありましたので列挙しておきます。
- ICGW-SDP基盤ではユーザビリティ向上に注力して開発できる
- ICGW-SDP基盤で対応しない限りユーザに見えることはないので、ICGW-core基盤での新規機能開発がやりやすい
- サービス仕様やユーザビリティの観点でユーザに見せたくない情報があった場合に、それらをICGW-SDP基盤側でコントロールしやすい
CI/CD
我々のチームではGUI開発、API開発、CI/CDともにNTT Comの内製ツールであるQmonusシリーズというものを利用しています。 特にCI/CDを司るQmonus Value Stream (Qmonus VS)に関しては、開発者ブログに紹介記事がありますので、詳細はそちらをご覧ください。
[DevOpsプラットフォームの取り組み #1] Qmonus Value Streamの紹介
図5は実際のQmonus VSの画面で、新しいバージョンのAPIをステージング環境にデプロイした時の様子です。 Qmonus VSは基本的にGitのブランチマージをトリガーに、いくつかのステップを経てデプロイが実行されます。 ICGWチームでは特にAPIをデプロイする際に、APIの自動試験が実行されるようにステップを構成しており、テストをパスしなければロールバックするという実装になっています。
GUIの自動試験に関してはGithub Actionsを採用しており、同じくブランチマージや任意のタイミングで試験を実施できるようになっています。 また、図6のようにダッシュボードを活用することで、試験中のスナップショットや動画を保存し共有できるような機構も現在計画中です。
ICGWの可視化
SDP開発に伴い、私の方で開発者/企画者向けにいくつかの可視化ポータルをGCPを活用して作成してみましたので、この場でご紹介します。
APIリクエスト数
こちらはAPIのリクエスト数をレスポンスコードごとに可視化したグラフです。 ICGW-SDP基盤で提供しているIFがどの時間帯にどれくらい利用されているか、500番エラーが多発していないかといった観点のために作成しました。 また、エラーの内容からユーザの間違えやすい傾向なども分析でき、ユーザビリティ向上にも活用できます。 アラート機能と組み合わせることで、リクエスト数の条件に応じてメールやSlack通知を発行することも可能です。
図8が可視化のための全体アーキテクチャです。以下のステップで構成しています。
- ユーザのAPIリクエストログをLoggingに転送する
- レスポンスコードごとに該当のログを抽出できるようにフィルタを追加する
- ステップ2で抽出したログに対してMonitoring上でカウントしグラフ化する
リソース利用状況
こちらは全ユーザの設定情報やトラフィック情報をもとに、リソースの利用状況とサービスごとのトラフィック量を時系列的に可視化したポータルです。 どれくらいの数のユーザがどのサービスを使っているかという市場分析用途で作成しました。 これらのグラフは開発者だけでなく企画者にもサービス展開を考える上でご活用いただいています。
図10が可視化のための全体アーキテクチャです。以下のステップで構成しています。
- 必要なデータを抽出するためのソースコードをStorageに保存する
- Functionsをビルドする
- SchedulerからFunctionsが定期的に実行される
- Funtionsによって抽出された各種データをBigQueryに保存する
- BigQueryに保存されたデータをData Studioで可視化する
これらの構成は全てIaaSとしてTerraform管理されており、ソースコードに変更が加わった場合はステップ1/2が自動で実行されるようになっています。 FunctionsからICGW基盤へAPIコールを行う際に、VPCを経由してCloud NATから出ていくことで外部IPを固定でき、ICGW基盤側でのアクセスコントロールが容易になっています。
Data Studioは同じくGoogleが提供している可視化ポータルで、権限があればBigQueryに保存されたデータも容易に読み込むことができ、データの更新も自動で行ってくれます。 また、作成した可視化ポータルは共有リンクを取得することで簡単にチームメンバーへ展開できます。
おわりに
ICGW SDP開発のリーダーとして、今回は開発の裏側(？)を紹介しました。 私自身は開発やCI/CDに関してまだまだ勉強途中であり、試行錯誤しながら挑戦しているところなので、より良い手法や開発スタイルがあれば取り込んでいきたいです。 また、今回の可視化ポータルのように、実際に構成を考えて自分の手を動かしてシステムを作っていくことには今後も挑戦できたらと思います。
本記事を通して、ICGWにも興味を持っていただけたら幸いです！
