IoTサービスをマルチテナント化したので、理由・効果・苦労をまとめました
こんにちは、imaimaiです。
クラウドサービスを用いることで、我々は柔軟にインフラアーキテクチャを設計できるようになってきました。逆に言うと、SaaSを提供している以上、組織の向かう先を見すえながらインフラを設計していかなければなりません。
昨年、iSTCはiXacsという、工場の生産状況を可視化するIoTサービスをリリースしました。その内容は下記記事にまとめています。
今年一年間は、更にインフラを洗練させていくために、サービスのマルチテナント化に取り組みました。開発も一段落し、実際にきちんと運用が回り始めたので、まだまだ発展途上ではありますが記事にまとめてみようと思います。
シングルテナント vs マルチテナント
そもそもマルチテナントって何！？という方もいると思います。ざっくりとした違いをまとめてみました。これらのメリット・デメリットをみてもわかる通り、どちらが優れているかの議論ができるようなものではなく、双方の良し悪しを把握し、どちらが適切かを考えることが大切だと思います。
マルチテナントに至った狙いと実際の効果
マルチテナント化の狙いは大きく3つありました。
☑ スケールメリットによるコスト効果
☑ 開発の柔軟性・機動力向上
☑ 運用体制へのアジャスト
今後の顧客拡大に向けて、インフラ側はスケールメリットが出る構成にしたいと考えていました。iXacsはサービスやデータの性質上、個別のカスタマイズの範囲が限られたパッケージ色が強いサービスになっています。（故に低コストでのサービス提供を実現しています。）移行前でも個別カスタマイズはほとんど行われておらず、マルチテナントへ移行してもデメリットはあまりないだろうと思いました。
また、マルチテナント構成は、初期に各サービス単位でコンテナリソースを確保する必要があります初期コストはかかるものの、集約により1社あたりにかかるコスト増を抑えることができるため、どこかで損益分岐点があります。iSTCの顧客数やこの先の伸びを考え、そろそろ分岐点近くかなと思っい、移行に踏み切りました。
実際に構築後、コスト増分のシミュレーションをしました。現在の顧客数がちょうど損益分岐点付近にいて、新規顧客1社あたりのコスト増分を5%-10%程度に抑えることができるので、すでに現段階で移行の効果は現れ始めています。
マルチテナントを実現するために、マイクロサービスアーキテクチャを採用しました。これによりサービス間の独立性を上げ、新規のサービスや新しい技術の検証時に、既存サービスを気にすることなくプロジェクト進行が可能です。コアサービスであるiXacsはかなりシンプルで本質的なデータを集めているため、その発展となる新規サービスのPoCをスピード感を持って行うことが狙いです。
iSTC内にマイクロサービスの知見が多くあるわけではなく、壁も多くありましたが（後ろの苦労点で詳述）、開発の中でクリアしていき、知見もかなり溜まったと思います。
iXacsサービスのメイン部分はJavaで作られています。実際に新規サービスのモックを別のスキルスタック(Golang+React)で作ってみようと思い、もくもく開発合宿を実施してみました。結果、他のサービスにほとんど干渉することなく、3日程度でサービスデプロイまで実現できました。MVP(Minimum Value Product)の作成やPoCのスピードアップに貢献できそうです。
マルチテナントのデメリットの一つに、サービス障害がお客様全体に影響するというところが挙げられます。しかし、シングルテナント運用の経験から、非同期的に障害が出ると対応がかなり大変で後手に回りがちであったこと、インフラとしてはそもそも障害が起こりにくい構成を用意すべきで、コスト的にも、アーキテクチャ的にもマルチテナントのほうが冗長構成を組みやすいというところがポイントでした。
また、新規顧客を獲得したときの運用も大きく変わります。シングルテナント構成だと、DB/NW/コンテナ設定を個別に行わなければなりませんでした。作成はある程度自動化されていたものの、個別設定の箇所もあり、意外と工数の掛かる作業でした。マルチテナント構成だと、新たにコンテナ作成をする必要はなく、サービス上で顧客追加をするだけで済むため、大幅な工数削減が実現しています。
以上がメインの理由です。書いていて、やはり組織の性質や方向性が大きく影響しているなと改めて感じました。
実際のアーキテクチャと工夫点
さて、理由が長くなりましたが、ここで実際のアーキテクチャと、工夫したポイント等を紹介できればなと思います。※iSTCではAWSを用いているので、AWSのサービスに準じた説明になります。
☑ アーキテクチャ全体像
ネットワーク : Web閲覧部とIoT収集部で分けている。IoT収集部のネットワークはセキュリティ確保のためVPN経由でデータを取り扱う。
コンテナ管理 : オーケストレーター(ECS)を使って運用。CPU負荷に応じたスケーリングやB/Gデプロイを実施。環境をdev/pre/prodと3種類用意し、旭鉄工の環境をpreに配置し。本番環境かつ実験環境という恵まれた環境で検証を行えるようにしている。
監視 : XrayとCloudWatchを利用。本番環境への移行前にパフォーマンス劣化が見つかり、Xrayを導入。(苦労点で後述)
データ収集 : RDB(RDS)に基本的なデータ。セッション情報と、高速で取り出したい一時的な情報はRedis(Elasticache)。パフォーマンス劣化を防ぐため、時間に応じてS3へ退避というデータのライフサイクル設計
DevOps : GitLab RunnerとCodePipelineを用いてテストまで自動化。staging環境ではコード変更時にシミュレータが走り、データ整合性テストが走り、スラックに結果の通知が飛ぶことで品質を担保
☑ ECS内
ECS内のサービス構成は、下記のような構成を取っています。マネージャー、サービス、DB用のコンテナと3層に分かれていて、層内での結合はなく、層間をAPIで連携しています。マネージャはプロキシの役割を果たしていて、後段のサービスへの連携やアクセスログの取得などを担っています。
層内の連携はしない設計担っているので、サービス開発では前段のマネージャコンテナと後段のDBコンテナを意識するだけで良く、開発の効率UPを狙っています。
苦労した点と工夫点
実際に開発を進めていくと、いろいろな壁にぶち当たりました。自分の経験不足から来る点も数多くありますが、本番運用前に体制を整えられたのは怪我の功名かなと思っています。そのなかでも特に大変だったところを3つほど。
☑ パフォーマンス劣化時の原因特定
☑ コンテナ間のリソース利用率の偏り
☑ テストの強化
【パフォーマンス劣化時の原因特定】
シングルテナントからマルチテナントへ本番環境を移行する前に、pre環境で大幅なパフォーマンス劣化が発生しました。コンテナが段階的につながっているマイクロサービスアーキテクチャでは、準備していないとどのコンテナが原因か特定することが困難です(トレーサビリティ問題)。そのため、このパフォーマンス問題の原因特定自体に時間がかかりました。
実際には、試行錯誤しながら下記のようなことを行いました。
・DB/キャッシュ/コンテナなどインフラのどの部分がサチっているのか、CloudWatchのダッシュボードで可視化
・X-rayを用いたトレーサビリティの確保。どのコンテナの応答が遅いのかを把握
・スケーリングしたコンテナのリソース利用率が偏っている可能性があるため、CloudWatchのパフォーマンスモニタリングでリソースの偏りを監視
・より詳しい統計量(vmstat, netstat等)を見るため、コンテナ内にsshできるサービス(SSM)を用いてコンテナ内部に入り調査
こうして、もがきながらも原因にアタリをつけることができました。X-rayやCloudWatchもこの過程で整備しておきました。原因特定のための知見が多く溜まったのが怪我の功名でした。
【コンテナ間のリソース利用率の偏り】
先程「スケーリングしたコンテナのリソース利用率が偏っている可能性がある」という話をしましたが、実際にそうで、IoTデータ処理コンテナで偏りが生じていました。コンテナのスケーリングによってデータ処理の分散処理を試みましたが、実際はナイーブな分配ではかなり偏っていました。
理由は下図の通りで、コンテナへの割当ルールがイマイチだったことによります。工場には3秒に1個作られる部品もあれば、1時間で1個作られる部品もあり、飛んでくるデータ量はまちまちです。そのため、「製造ラインの数」から、「過去1週間の信号量で処理を動的に分配する」ように割当ルールを変更しました。現在は一日数回バッチ処理にて再割当てを行っており、リソースが平準化された状態をキープできています。
【テストの強化】
効率の良い開発を行うために、テストは不可欠です。特にiXacsのようなデータ収集を起点としたサービスでは、データの不整合は致命的になってしまいます。
注意は払っていながらも、実際には処理の組み合わせが多岐に及び、人力で整合性のチェックを行うには限界があります。これを自動化するため、チェック用のシミュレータを開発しました。gitlabのpushをトリガーにして、staging環境でシミュレータが自動的に走り、総合的なデータ処理の整合性チェックを行うようにしています。これにより品質を定量化できるようになりました。(このあたりの詳細はまたどこかで書こうかなと。)
まとめ
かなり長くなってしまいましたが、マルチテナント化に関わることを、できるだけ詳しく、正直に書いてみました。IoT系のサービスでここまで書いてあるものも珍しいのかなと思います。だれかの参考になれば嬉しいです(そしてもっとこうすればいいよ、というご意見もあると嬉しいです)。
過去記事にも変遷を書きましたが、この2年間でiXacsも当初からブラッシュアップが進みました。結構大変なことも多かったですが、かなり自分が理想とする形態になりました。スケールメリットや開発の機動力向上に手応えを感じ始めているので、今後どうなっていくか楽しみです。
まだまだ発展途上ですが、使い勝手や安定性もかなり洗練され、自信を持って勧められるサービスになってきています。生産性向上にお困りの方の製造業の方には、ぜひ一度試してもらいたいです！サービスの詳細はこちら。
ではではっ
サポートいただけると励みになります！ よろしくおねがいします！！