こんにちは、ソラコムのソリューションアーキテクト豊福 (ニックネーム: toyo) です。
本記事では、7月17日に開催されたSORACOM Discovery 2024内のセッション「徹底解説！大規模IoTを支えるSORACOMの技術基盤」の内容をご紹介します。
昨年のDiscovery 2023では、SORACOMプラットフォームの裏側としてPGW (Packet Data Network Gateway) /HSS (Home Subscriber Server) などモバイルコアシステムのアーキテクチャや、ローミングの仕組みをご紹介しました。
SORACOMはどうやって動いているのか？自社開発のコアネットワークの裏側までご紹介【SORACOM Discovery セッションレポート】
今年は、SORACOMプラットフォームで600万回線収容可能なスケーラビリティをどのように実現しているのか、お客様に安定してお使い頂くために運用面の取り組みを解説しました。
スピーカーは、ローコードIoTアプリケーションビルダー SORACOM Fluxの開発も手掛けたプリンシパルソフトウェアエンジニアの大熊 (ニックネーム: ogu) と、シニアソリューションアーキテクトの渡邊 (ニックネーム: dai) の2名でお届けしました。当日は会場最後部まで立ち見が出る盛況ぶりで、SORACOMプラットフォームの裏側について多くの方に知って頂ける機会となったのではないでしょうか。
SORACOMプラットフォームのスケーラビリティ
私たちソリューションアーキテクトは、PoCを目的として１回線からの利用を検討されているお客様から、社会インフラを扱う大規模なお客様まで、日々色々なお問い合わせを頂きます。様々な業種・規模のお客様にIoTのコネクティビティを提供するSORACOMプラットフォームのスケーラビリティは、どのように実現されているのでしょうか。
本セッションでは、以下３つのキーワードからその裏側をご紹介しました。
- APIファースト
- マイクロサービスアーキテクチャ
- 水平スケーラビリティ
APIファースト
１つ目のキーワードは「APIファースト」です。SORACOMでは2015年のサービス開始当初から、大量のSIMやIoT回線を管理する仕組みとして自動化が必要であることを想定し、ユーザーが使えるすべての機能をSORACOM API経由で使えるようプラットフォームを開発してきました。SORACOM APIをご利用頂くことで、ユーザコンソール上と同等の操作をお客様システムに組み込み、自動化することが可能です。
お客様にお使いいただくPublicなSORACOM APIだけでなく、SORACOMプラットフォーム内でもAPIが活用されています。例えばお客様によるユーザコンソール上のSIM・デバイス注文操作、配送センターとの連携、商品発送、SIMアクティベーションによるIoT通信開始といった、操作ははSORACOMプラットフォーム上でユーザ認証、注文管理といったBSS (Business Support System) /OSS (Operations Support System) 機能や、HSS/PGWといったモバイルコア機能がAPIを介して高度に連携することで実現されています。
SORACOMプラットフォームにおけるAPIの進化を、お客様向けに公開しているPublicなAPI数から見てみましょう。2015年のSORACOMサービス開始時点ではPublicなAPI数は43でしたが、Discovery2024基調講演でもご紹介した2週間に１回ペースの新機能/機能改善リリース (Pace of Innovation) を継続することで、2024年7月時点では10倍の448となっており、1日あたり3500万回も呼び出されています。
どうすればこれら大量のAPIリクエストを処理できるのでしょうか。まずSORACOMプラットフォームでは、独立した小さなサービス (マイクロサービス) が連携動作しており、必要な部分に必要な容量を追加することができます。この「マイクロサービスアーキテクチャ」によって、大量のAPIリクエストをバックエンドサーバ間で負荷分散することが可能です。さらにシステムに過大な負荷がかかるリクエストを抑制するスロットリングや、過負荷な状況を事前検知する監視の仕組みも、大量のAPIリクエストを安定的に運用するために重要な役割を担っています。
マイクロサービスアーキテクチャ
「マイクロサービスアーキテクチャ」についてもう少し見てみましょう。
SORACOMプラットフォームのアーキテクチャは2015年のサービス開始から基本的に変わっていません。大きくは、パケット転送、回線管理、帯域制御、アクセス制御などの通信を司る「Polaris」(ポラリス) と、セッション管理、認証、課金などのバックエンド処理を行う「Dipper」(ディッパー) で構成されており、複数の独立した小さなサービス (マイクロサービス) がAPI経由で連携しています。
2015年のサービス開始当初は仮想サーバーベース (Amazon Elastic Compute Cloud (EC2) ) でマイクロサービスを構成していましたが、近年では既にコンテナ化 (AWS Fargate for Amazon ECS) されています。テレコム業界でもここ数年モバイルコアのコンテナ化が始まっていますが、ソラコムではコアアプリケーションの開発・運用に集中するため、さらに一歩先のサーバレス化 (AWS Lambda) も進めています。
水平スケーラビリティ
３つ目のキーワードとしてSORACOMプラットフォームの「水平スケーラビリティ」についてご紹介します。
一般的にシステム容量を増強する手法として、垂直スケーラビリティ (スケールアップ) と水平スケーラビリティ (スケールアウト) の２つが存在します。垂直スケーラビリティはシステムを構成するサーバ自体の性能を向上させる方法ですが、容量増強時に対象サーバを停止する必要があり、稼働しているサービスへの影響が発生します。一方水平スケーラビリティはシステムを構成するコンポーネント (物理/仮想サーバ、コンテナ等) を追加することで容量を増強する手法で、基本的にサービスを完全に停止することなく実施可能です。
マイクロサービスアーキテクチャを採用するSORACOMプラットフォームでは、水平スケーラビリティ (スケールアウト) の手法で容量追加が可能で、Amazon EC2、Amazon ECS、Amazon DynamoDBについては自動スケールアウトで運用されています。AWS Lambdaで実装されているサービスについては、サーバレスのメリットとしてスケーリングに関してほぼ気にする必要がありません。
AWS上で稼働するSORACOMプラットフォームでは、AWS上のリソース使用量に応じてソラコムとしての運用コストが発生します。運用コストをなるべく抑えることでSORACOMプラットフォームをご利用頂くお客様にもコストメリットの高いIoTのサービスをお届けできるため、システム負荷の変動に合わせて柔軟な容量増強を可能にする水平スケーラビリティは、非常に重要な仕組みとなっています。
グローバル600万回線収容を支える運用の仕組み
ここまでSORACOMプラットフォームのシステム面で高いスケーラビリティを実現する仕組みをご紹介してきました。ただ、システム的に高いスケーラビリティを有しているだけでは、グローバル600万回線を収容し、さらにそれを安定運用させることはできません。世界中で使えるコネクティビティを提供する仕組みと、それを支えるソラコムの「人」、運用体制についてもご紹介したいと思います。
世界中で使えるコネクティビティを提供する仕組み =「ローミング接続」
2024年7月時点、ソラコムは182を超える国と地域、417通信事業者との接続を提供しています。ソラコムのみでこれら全ての国と地域への接続性を確保するのは非常に大変に思えますが、どのように実現されているのでしょうか。
このグローバルなコネクティビティは、他通信事業者のネットワークを借りる「ローミング」と呼ばれる仕組みで実現されています。ただしローミング接続するためには、ローミング契約の締結、詳細なパラメータの調整を含むネットワーク設計、それに基づくネットワーク構築、接続試験などを、接続先事業者毎に実施する必要があります。
このローミング接続に必要な全ての作業を全ての接続先通信事業者と実施するのは非常に大変なため、IPX (IP Exchange) と呼ばれるローミング中継事業者を経由して、対向通信事業者と接続しています。なお、1社のIPXで全ての国と地域をカバーできるわけではないため、現在ソラコムでは、複数のIPXと契約・接続することで、グローバルなコネクティビティを提供しております。
Andon
APIによる自動化同様、障害の検知から復旧まで、極力自動で対応できるようSORACOMプラットフォームを進化させてきました。何か異常が検知された場合、異常内容に応じてプロセス再起動や系切り替え (Active <> Standby) が自動で実行され、それでも復旧できない場合にサポートメンバーが呼び出される運用となっています。
一方システムのスケールが大きくなることで、いわゆる「いつも必ずどこかが壊れている」状態が発生し得ます。そのような状況でも可能な限りお客様に影響を与えないよう、ソラコムではトヨタ生産方式の製造管理システム「アンドン」に由来する、Andonと呼ばれる障害対応プロセスを運用しています。
ソラコムは内部のコラボレーションツールとしてSlackを利用していますが、SORACOMプラットフォームに何か障害が発生している可能性に気付いたメンバーは、Slack上の専用チャネルに検知された事象を報告します。 (ソラコム内では「Andonが引かれた」と表現します) 。
一旦Andonが引かれると、Andon解消を最優先として様々なメンバーがSlack上のVirtual War Roomで動き始めます。被疑箇所絞り込みのためのKPIやログチェック、ローミング接続先への調査依頼、影響を受けるお客様範囲の確認などが並行して行われ、機能開発を行なっているエンジニアや、お客様構成により詳しいソリューションアーキテクト、セールスメンバも参加し、協力して最短での障害復旧を目指します。
Platform Guardians
SORACOMプラットフォームは様々なコンポーネントを使用していますが、不要なリソースや適切でない設定が存在しないか、Platform Guardiansという取り組みで日々監視・改善しています。
SORACOMプラットフォームではシステム健全性をレポートする10数種類のAWS Lambdaが1日1回動作しています。エンジニア３名がランダムにPlatform Guardiansとして選ばれ、持ち回りで毎朝30分間レポートを確認し、何か対処が必要な場合には、関連するメンバーに改善を依頼します。この取り組みを通じて、限られたメンバーに依存せず、自分ごと化してSORACOMプラットフォームを健全に維持・運用できるようになることを目指しています。
セキュリテイ上の取り組み
ソラコムでは、これまでも総務省ガイドラインに則ったセキュリティチェックシートの公開やISMS (ISO/IEC 27001:2013) 認証取得を通じて、セキュリティに対する信頼性向上に取り組んで参りました。さらに2024年7月には、IoTプラットフォーム「SORACOM」に対してセキュリティおよび機密保持の内部統制を評価する、SOC2 Type1保障報告書を受領しました。詳細は以下SAブログ、Discoveryセッション資料をご覧ください。
安全と運用の証明「SOC2」担当者が語る取得の意義と取り組み【SORACOM Discovery 2024】
別の取り組みとして、セキュリティ上の問題を発見した外部のホワイトハッカーに対して報奨金を提供するBug Bounty Programも運用しており、継続的なSORACOMプラットフォームのセキュリティ向上に努めています。
まとめ
いかがだったでしょうか。SORACOM公式ブログ、SORACOMサービス更新情報、展示会では、ソラコムの新しいサービス、デバイスについてお届けすることはできても、SORACOMプラットフォームの裏側や運用の工夫をご紹介できる機会はあまりありませんでした。今回の記事が、SORACOMプラットフォームとその運用体制についてより知って頂くきっかけとなれば幸いです。
今後もより多くのお客様に安心してIoTコネクティビティ/サービスをご利用いただけるよう、継続してSORACOMプラットフォームと運用の仕組みを改善して参ります。
― ソラコム豊福 (toyo)