ここから本文です

スケーラブルなIoTプラットフォーム「SORACOM」はこう作られた

アスキー 4/21(金) 7:00配信

IoTプラットフォームを手がけるソラコムは、開発者向けイベント「if-up 2017」でSORACOMの中身を披露した。
4月20日、IoTプラットフォームを展開するソラコムは初の開発者向けイベント「if-up 2017」を開催した。キーノートに登壇したソラコムCTOの安川健太氏は、グローバルにスケールできるSORACOMのアーキテクチャや開発ポリシーなどを参加者に詳説した。
 

SORACOMを支える3つの構成要素
 SORACOMは、ネットワークやセキュリティ、デバイス管理、クラウドとの接続などIoTサービス開発における障害を取り除き、アプリケーション開発に集中できるさまざまなサービスを提供している。データ通信サービスの「SORACOM Air」をベースに、暗号化などの処理をオフロードする「SORACOM Beam」、VPCへの接続を行なう「SORACOM Canal」、他のクラウドと直結する「SORACOM Direct」「SORACOM Door」、SIMによる認証サービス「SORACOM Endorse」、デバイスデータをクラウドに転送する「SORACOM Funnel」、IoTデバイスとLAN接続する「SORACOM Gate」、データの収集と蓄積を行なう「SORACOM Harvest」などが展開されている。昨今では、セルラーのSORACOM Airのみならず、LPWAとして有望なLoRaWANへの取り組みもスタートし、プラットフォームとしての利用価値をますます高めている。
 
 こうしたSORACOMのプラットフォームは、ロゴマークにちなんで大きく3つの構成要素から成り立っている。パケット転送や帯域・アクセス制御、アプリケーションサービスを担う「Polaris」(北斗星)、回線・セッション管理、認証、課金、イベント通知、コンソールなどを提供する「Dipper」(北斗七星)、サービスの監視とデプロイを行なう「Hubble」の3つで構成されている。これらのシステムはそれぞれAPIで連携するさまざまなコンポーネントで成り立っている。「われわれローンチ以来、このアーキテクチャを変えていない」と安川氏は語る。
 
スケーラブルで耐障害性の高いプラットフォームを支えるポリシー
 ソラコムはスケーラブルなIoTプラットフォームを構築するため、「拡張性と可用性を担保すること」「技術的に新しいことができること」「プラットフォーム自体が成長できること」「効率的に運用できること」などを重視。これらを実現するための開発ポリシーについて、安川氏は説明する。
 
 1つ目は「水平的なスケーラビリティと組み込み型の耐障害性(Horizontal ScalabirityとBuilt-in Resilience)」というポリシーだ。SORACOMでは5000以上のユーザーの利用に耐え、デバイス増加の負荷に応じて、サーバーの台数が増やすことができる。また、単一障害点(SPOF)のない構成になっているため、対障害性がきわめて高い。「マイクロサービスのみならず、データベースも含め、全レイヤーにHorizontal ScalabirityとBuilt-in Resilienceの思想を組み込んでいる」(安川氏)という点が特徴だという。
 
 2つ目の「グローバル前提の設計とレイヤー構造のアーキテクチャ」は、SORACOMがグローバルに対して迅速にサービスを展開できた原動力になる。たとえば、コンソールはHTMLとJavaScriptを用いたシングルページアプリケーションで、ユーザーの操作でAPIを呼び出し、SIMの管理機能を提供する。そのため、コンソールの開発者はプログラムをAmazon S3にアップデートすれば、CloudFrontを経由して、自動的にグローバルに展開できるようにしてあるという。コンソール自体もローンチ時から日本語・英語対応で、システム自体もUTCの時刻で設計されている。
 
 また、SORACOMはサービス自体がSORACOM Airを基盤にしたレイヤー構造のアーキテクチャになっている。そのため、SORACOM Airの利用範囲が拡がれば、上位のサービスもそのまま利用できる。昨年来からのグローバル展開やLoRaWANに迅速に対応できたのも、こうした仕組みを設計当初から組み込んでいたからだという。安川氏は、「IoTではユースケースごとに適した無線技術が違うのが当たり前。今後、さまざまな無線規格や技術が出てきても、SORACOMであればスムーズに対応できる」とアピールした。
 
疎結合化・非同期化の推進とDevOpsの実践
 3つ目の「疎結合化と非同期化」も、迅速なサービス展開に大きく貢献している。ソラコムはサービス立ち上げから約1年半のうちで、大きなリリースを12回、新機能の発表を38回行なっているが、このスピードを実現できるのもこの疎結合化と非同期化のおかげだという。
 
 たとえば、課金の部分。SORACOMではパケット転送を行なうPolarisが転送データ量を集計しており、ある程度まとまった段階でAmazon S3に集計を転送。アップロードが完了すると通知が行き、課金処理が行なわれるという仕組みになっている。
 
 また、クラウドサービスごとにプロトコル変換、認証、バッファリング、エラー処理などを請け負ってくれるリソースアダプターのSORACOM Funnelに関しては、サービスごとにAWS Lambdaのファンクションを用意。「サービスの差分だけを実装すればよいので、速いスピードでサービスを追加できる。この仕組みを使って、パートナーのサービス連携を迅速に進めていきたい」と安川氏は語る。
 
 安川氏はこうした疎結合化と非同期化のメリットについて「仮に課金システムがダウンしてたり、処理が遅くなっても、パケット転送やデータ集計の部分は動き続ける。あと、両者を担当するエンジニアも独立してメンテナンスできる」とアピールした。
 
 4つ目はいわゆるDevOpsの実現。ソラコムでは各コンポーネントを担当するプライマリーオーナーが決められており、彼らが開発・メンテナンス・運用まですべてに携わっている。「すなわちソラコムの開発者はDevOpsを実践するメンバー」(安川氏)とのことで、各オーナーが責任を持って攻めの開発を進めているという。
 
 とはいえ、攻めの開発ばかりしていて、守りの運用が大変になるというのはよくある話。これに対してソラコムは、運用中心のOpsDevエンジニアを入れることで、この問題を回避している。「たとえば、監視の仕組みを作ったり、繰り返し作業を自動化する部分を作っている。SORACOMでいうと、いわゆるHubbleが、OpsDevエンジニアが担っているシステム」と安川氏は説明する。
 
 HubbleはSORACOMのシステムを常時監視しており、障害時はいち早くSlack上に通知し、自動復旧を試みる。たとえば、プロセスを復旧したり、インスタンスを置き換え、解決した場合はここでクローズ。解決しない場合は、エンジニアに電話し、復旧まで進めるという。さらに新サービスの登場で監視項目が増える場合も、各インスタンスにロールをタグ付けし、OpsDevエンジニアに監視について説明。OpsDevエンジニアはロールごとに監視方法や復旧方法を設定していくという。
 
 安川氏がここまで中身を明らかにしたのも、他社に追従できない自信の表れの言える。テクノロジーのみならず、サービスの設計思想、人材、チームビルディングなどさまざまな要素が最適化されていなければ、ここまでのシステムは実現できないからだ。最後、安川氏はこうした一連のポリシーやテクノロジーについて会場のみなさんと語り合いたいとアピール。「ソラコムはクラウドの上にビルドアップしてきたIoTのためのプラットフォーム。SORACOMの上にみなさんのアプリケーションをビルドアップしていただければ、イノベーションを起こすことに集中できると思う」と語り、セッションを終えた。
 
 
文● 大谷イビサ/TECH.ASCII.jp

最終更新:4/21(金) 7:00

アスキー