初の開発者向けイベント「if-up 207」で明かされたSORACOMの中身

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

疎結合化・非同期化の推進とDevOpsの実践

　3つ目の「疎結合化と非同期化」も、迅速なサービス展開に大きく貢献している。ソラコムはサービス立ち上げから約1年半のうちで、大きなリリースを12回、新機能の発表を38回行なっているが、このスピードを実現できるのもこの疎結合化と非同期化のおかげだという。

　たとえば、課金の部分。SORACOMではパケット転送を行なうPolarisが転送データ量を集計しており、ある程度まとまった段階でAmazon S3に集計を転送。アップロードが完了すると通知が行き、課金処理が行なわれるという仕組みになっている。

課金システムも疎結合化・非同期化を実現

　また、クラウドサービスごとにプロトコル変換、認証、バッファリング、エラー処理などを請け負ってくれるリソースアダプターのSORACOM Funnelに関しては、サービスごとにAWS Lambdaのファンクションを用意。「サービスの差分だけを実装すればよいので、速いスピードでサービスを追加できる。この仕組みを使って、パートナーのサービス連携を迅速に進めていきたい」と安川氏は語る。

初公開となるSORACOM Funnelの内部アーキテクチャ

　安川氏はこうした疎結合化と非同期化のメリットについて「仮に課金システムがダウンしてたり、処理が遅くなっても、パケット転送やデータ集計の部分は動き続ける。あと、両者を担当するエンジニアも独立してメンテナンスできる」とアピールした。

　4つ目はいわゆるDevOpsの実現。ソラコムでは各コンポーネントを担当するプライマリーオーナーが決められており、彼らが開発・メンテナンス・運用まですべてに携わっている。「すなわちソラコムの開発者はDevOpsを実践するメンバー」（安川氏）とのことで、各オーナーが責任を持って攻めの開発を進めているという。

ソラコムの開発者は全員がDevOpsを実践

　とはいえ、攻めの開発ばかりしていて、守りの運用が大変になるというのはよくある話。これに対してソラコムは、運用中心のOpsDevエンジニアを入れることで、この問題を回避している。「たとえば、監視の仕組みを作ったり、繰り返し作業を自動化する部分を作っている。SORACOMでいうと、いわゆるHubbleが、OpsDevエンジニアが担っているシステム」と安川氏は説明する。

　HubbleはSORACOMのシステムを常時監視しており、障害時はいち早くSlack上に通知し、自動復旧を試みる。たとえば、プロセスを復旧したり、インスタンスを置き換え、解決した場合はここでクローズ。解決しない場合は、エンジニアに電話し、復旧まで進めるという。さらに新サービスの登場で監視項目が増える場合も、各インスタンスにロールをタグ付けし、OpsDevエンジニアに監視について説明。OpsDevエンジニアはロールごとに監視方法や復旧方法を設定していくという。

IoTスケールなプラットフォームを実現するためのソラコムのポリシー

　安川氏がここまで中身を明らかにしたのも、他社に追従できない自信の表れの言える。テクノロジーのみならず、サービスの設計思想、人材、チームビルディングなどさまざまな要素が最適化されていなければ、ここまでのシステムは実現できないからだ。最後、安川氏はこうした一連のポリシーやテクノロジーについて会場のみなさんと語り合いたいとアピール。「ソラコムはクラウドの上にビルドアップしてきたIoTのためのプラットフォーム。SORACOMの上にみなさんのアプリケーションをビルドアップしていただければ、イノベーションを起こすことに集中できると思う」と語り、セッションを終えた。

■関連サイト

• ソラコム