ソラコムは、AWS上にミッションクリティカルなシステムをどう構築し、運用しているのか。IoTプラットフォーム開発と運用を聞いた[PR]

2019年6月24日

パブリッククラウドであるAWS(Amazon Web Services)の上に、セルラー通信網に対応したパケット交換や帯域制御、顧客管理、課金機能などを構築することで、IoTデバイス向けの通信サービスを提供するスタートアップ企業として登場したソラコム

同社はサービスの根幹にかかわるミッションクリティカルな機能を含むあらゆるサービスと業務システムを、AWS上に構築し運用するというチャレンジングな試みを実現し、サービス開始後3年半でIoT回線100万回線を達成。サービス面でもビジネス面でも成功を収めてきました。

fig写真左から、株式会社ソラコム 執行役員プリンシパルソフトウエアエンジニア 片山暁雄氏、代表取締役社長 玉川憲氏

現在、同社は自社でSIMを発行するいわゆる「フルMVNO」となり、NTTドコモとKDDIの国内セルラー網に加えて世界130の国と地域の通信キャリアや、LoRaWAN、Sigfoxなどの新通信規格にも対応。

さらに認証や暗号化などのセキュリティ、データ転送、収集、蓄積、分析、デバイス管理などのIoTアプリケーションのためのアプリケーションスタック、LTE対応のボタンデバイスや通信モジュールキットなどIoTデバイスの提供まで、さまざまなサービスから構成されたグローバルなIoT向けプラットフォームを展開するまでになっています。

fig

世界中で使える翻訳デバイスの「POCKETALK(ポケトーク)」や、ダイドードリンコのIoT自販機「Smile Stand」など多くの事例がソラコムのプラットフォームで実現されており、1万5000もの顧客と500社ものパートナーへとエコシステムが広がっています。

このようなミッションクリティカルかつグローバルなサービスをAWS上のクラウドネイティブな開発で実現してきた同社の開発と運用体制は、どのようなものだったのでしょうか。

同社代表取締役社長 玉川憲氏と、執行役員プリンシパルソフトウエアエンジニア 片山暁雄氏に聞きました。

AWS上でミッションクリティカルなシステムをどう開発しているのか?

──── ソラコムが2015年9月にはじめて発表したサービス「SORACOM Air」は、キャリアグレードのIoT向け通信インフラをパブリッククラウドのAWS上に構築するというものでした。パブリッククラウドにミッションクリティカルな通信システムを実装するというのは、当時はもちろん現在でも非常にチャレンジングな試みだと思います。どう実現したのか、まずは技術的な面から教えていただけませんか?

玉川氏 たしかに当時から『無理じゃないですか?』という反応もありました(笑)。この3年半、ビジネスとして成立してきたことで、難しいけれどできた、ということが立証されたのではないかと思います。

片山氏 ソラコムの通信インフラの中心は、「Polaris(ポラリス)」と呼ばれるパケット転送や帯域制御などの通信を司る部分と、「Dipper(ディッパー)」と呼ばれる認証や課金などのバックエンド処理を行う部分から構成されています。

Polarisは通信コア機能を分散システムとして実装していて、各機能を司るインスタンスを複数起動してそれぞれが自律的に障害を検出し、修復する動作を行うことで耐障害性を高めています。

Dipperディッパーも複数のアベイラビリティゾーンを利用し、単一障害点がないような仕組みにしています。

fig

これを「Hubble(ハッブル)」と呼んでいるZabbixを中心とした監視システムで常時監視し、異常を検知したら、プロセスの再起動や、インスタンス障害であれば新しいインスタンスをプロビジョニングすることによって、単一障害であれば人の手を介さずに自動で復旧します。

通信ステートはAWSのDynamoDBで管理されているため、フェイルオーバーしても新しいインスタンスがステートを引き継ぐことでセッションが切れることなく別のインスタンス経由で通信が届きます。そのためお客様はそのまま通信を続けることができます。

──── いわゆるマイクロサービスアーキテクチャ的なものを4年前から作り込んでいた、ということですね。

片山氏 高可用性を実現する方法はいろいろありますが、創業当初から弊社はクラウドの「グル」(Guru)的なメンバーが集まっていたこともあって、最初からこういう方針でいこうというのはすんなり決まりました。

玉川氏 私たちはクラウドを信頼している一方で、Amazon.comのCTOであるワーナー・ボーゲルス氏の「Everything Fails」(壊れないものはない)という言葉も信頼しています。つまり、クラウドのコンポーネントは基本的に壊れるものとして扱って、壊れたらすぐに別のインスタンスにフェイルオーバーする、ということを最初から考えていました。

それでもサービス開始当時からの3年半前を振り返ってみると、現在のソラコムのユーザー数やグローバル展開の規模になってはじめて見えてくる課題というものがやっぱりありました。

そうした課題も数多く解決してきたので、当時と比べると現在の方が信頼性のためのいろんな仕組みがさらに整っています。

──── 開発チームや開発体制はどうだったのでしょうか?

玉川氏 開発が始まったのは2015年3月で、当時はCTOの安川を始め10人程度の社員全員がエンジニアでした。半年後の9月に最初のサービスである「SORACOM Air」をはじめとするサービスのリリースに向けて、一人でも欠けたらみんな倒れてしまうような勢いで開発を進めていました。

片山氏 最初から2週間ごとのスプリントを繰り返しながら開発を進めてきました。プロダクトオーナー的なものはCEOの玉川がやっていましたが、2017年頃にサービスが増えてきて全部を見切れなくなったため、その頃にプロダクトオーナーを複数人で担当し始めました。

fig

2018年以降に作り始めたプロダクトやサービスにはプロダクトオーナーをそれぞれつけて、仕様やアーキテクチャを決めたり、プレスリリースを書いたり、そういうのを担当してもらっています。

エンジニアは創業から数年は特にかっちりとしたチーム分けもなく、やるべきタスクを個々のエンジニアごとに決めていましたが、エンジニアが20人を超えた頃に、7つの「スクワッド」と呼ぶチームに分けるようにしました。そのうえで、会社全体のプロダクト開発を調整する担当者を置いています。

開発が運用にも責任を持つ。運用改善のための職種「OpsDev」も

──── 運用についてもお聞きしたいと思います。ミッションクリティカルなシステムの運用は、一般には24時間365日のシフト体制など大がかりな体制が必要と考えられていますが、ソラコムはシステムの自動復旧を徹底的に強化するなどで少人数で効率的な運用体制を実現していますね。

玉川氏 最初からそういう運用ができるように作り込みをしてきました。もちろんこれまでには障害も経験しましたが、そのときも原因を分析し、対策を作り込んできました。

というのも、われわれは非常に大きな市場を狙っているという前提で、そのためにはシステムがビジネスのスケールの阻害要因になってはいけないと考えていたためです。規模が大きくなっても運用の工数が増えないように、とにかくシステム自身が自動で復旧できるように作る、というのはビジネス面で重要だという認識がありました。

ですから「開発者は運用の責任も持つ」と最初から決めて、運用のことも考えた開発を進めてきていますし、開発組織が大きくなった2017年頃からは、開発リソースの15%をシステムの運用向上や改善に充てることを明確にしています。

さらに社内には「OpsDev」という、運用向上や改善のための開発を行う職種のエンジニアもいます。Googleが提唱するSRE(Site Reliability Engineer)のような立場ですね。

片山氏 私たちは2週間の単位でスプリントを設定して開発を行っています。この2週間ごとに計算されるエンジニア全体の開発工数の15%を、運用改善のチケットに割り当てるようにしています。

必ずしもその全部をOpsDevエンジニアに割り当てるわけではなく、関係するエンジニアやチームが担当することもあります。また、3カ月ごとの四半期レビューでは、この四半期でどんなことをやるのか、何が課題で取り組みべきなのか、エンジニアみんなで相談しています。

そのOpsDevエンジニアのこだわりとして、システムの多重化によってシステム全体としては壊れないようにすること、そして運用の手順書に落とせることは自動化できるはずだから、そこは徹底的に自動化してシステム自身でまかなえるようにする、ということをしています。

一方で優秀な運用担当者は、例えばメトリクスをぱっとみるとなんとなく問題が分かる、といった能力があったりします。こういう能力は運用で手順化しにくく、自動化も難しいものですが障害の早期対応には非常に大事です。こうした部分は社内で勉強会などを開いてスキルを共有し、人間系の運用能力向上も積極的に行っています。

fig

IoTのハードルを下げるというニーズがあると分かった

──── 2015年9月に最初のサービスを発表してから、新しいサービスが次々に登場していますが、「次にどのようなサービスを作るか」は、どう決めているのですか?

玉川氏 「SORACOM Air」に加えて、通信データを転送する「Beam」、プライベートクラウドとの接続をする「Canal」などをリリースした後も、認証や外部との接続などのニーズがあるだろうなと考えて、それらを実現する「Endorse」「Funnel」などをリリースしましたが、創業当初に構想していたサービスはこのあたりまででした。

ただ、実際にサービスをお客様に使っていただいて分かってきたのは、われわれのサービスというのは、異なる業種をつないでいるんだな、ということでした。

例えば製造業でIoTを活用したいと思ってソラコムを利用していただいているお客様にとっては、われわれIT業界の人間からするとクラウドを使っていろいろできるだろうと思っていたことも、結構ハードルが高いことだということを知りました。

片山氏 例えばIoTデバイスから得られたデータをグラフにするのも、Amazon S3にデータが入ったらあとは簡単ではないかとわれわれは思っていたのですが、お客様としてはもっと簡単にしてほしいと、できればソラコムのサービスで全部できるならその方がいい、というニーズが見えてきました。

当初はそこまではソラコムで作るところじゃないのでは、と思っていたのですが、お客様のフィードバックをいただいて考えが変わりました。

そこで開発した、データを簡単にグラフ化できるサービス「Harvest」は、いまや「Air」の次に多く使われているサービスになっています。

玉川氏 IoTのハードルを下げるという意味では、IoTではなんらかの通信モジュールをデバイスに組み込む必要があるため、このハードウェア面で行き詰まるお客様がいることも分かってきました。

そこで最近では、ハードウェアにもわれわれの範囲を広げて、デバイス面でのリファレンスになる「リファレンスデバイス」を用意することも始めています。

fig玉川氏が手にしているのはリファレンスデバイスの1つ「SORACOM LTE-M Button for Enterprise」

最初は体力がなくてそれほどの種類はなかったのですが、現在ではサードパーティの認定デバイスに加えて、ソラコム自身がUSBドングル形式のLTE対応データ通信端末、Sigfoxデバイス、LTE-Mボタン、IoTスターターキットなどを提供しています。

figリファレンスデバイスの例。「Grove IoT スターターキット for SORACOM」「Sigfox Shield for Arduino」「SORACOM LTE-M Button powered by AWS」「Sens'it」

玉川氏 IoTのハードルを下げるということがわれわれにとって重要になってきた一方で、従来なら通信事業者しか利用できなかったようなSIM認証に基づくセキュアなプロビジョニングができる「Krypton」や、ダッシュボードを共有する「Lagoon」など、とがったサービスもリリースしています。両方のバランスをとっていきたいですね。

サービスの開発スピードがさらに充実してきた

──── ソラコムはIoTの通信インフラ、関連サービス、さらにデバイスまで加わったことで、IoTのプラットフォームとして展開されるようになりました。

玉川氏 IoTデバイスまで手がけるようになったことで、IoTソリューションのベストプラクティスがどういうものか、私たち自身が分かるようになってきました。

私や片山がAWSにいた頃、クラウドのベストプラクティスを集めた「クラウドデザインパターン」といったものを作りました。IoTにおいても、もうすぐIoTソリューションのベストプラクティスを集めたデザインパターンが作れるのではないかと思います。

──── これだけ範囲が広がると、サービスの開発体制やスピードにも変化があるのではないですか?

玉川氏 開発スピードはわれわれの強みでもあると思っているので、スピードが落ちないようにいつも考えています。

以前は自社イベントのタイミングに合わせて新サービスが発表できるように、みんなでイベントぎりぎりまで頑張って取り組んでいた、という感じでした。

いまは以前よりしっかりサービスを作れる体制が充実して、7月2日のイベント「SORACOM Discovery 2019」で発表する予定の多くの新サービスや新機能はすでに出来上がっています。プライベートベータとしてお客さんに評価してもらっている状態ですので、より高い完成度でリリースできると思っています。

「SORACOM Discovery 2019」では、皆様のIoTビジネスに貢献できる新しいサービスを発表する予定です。ぜひ期待してご来場いただければと思います。

≫SORACOM Discovery 2019
(2019年7月2日 ​グランドプリンスホテル新高輪 ​国際館パミール)

fig

(本記事は株式会社ソラコム提供のタイアップ記事です)

このエントリーをはてなブックマークに追加
follow us in feedly




カテゴリ

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本