こんにちは、インフラチームの橋爪です。
LANSCOPE クラウド版の、インフラチームのリーダーをしています。2018年末にインフラチームが出来てから、3年が経ちました。改めて、この3年間インフラチームが取り組んできたことを振り返りたいと思います。
インフラチームができた経緯
LANSCOPE クラウド版は、MDM（モバイルデバイス管理）製品として、2012年から販売しています。当初から SaaS 製品として提供してきましたが、2018年の バージョン3.0 リリースに合わせて、一からシステムの作り変えを行っています。
作り変えることになった経緯については、こちらの記事もご参照ください。
「オンプレミスのパッケージ製品からマルチテナントのSaaS製品へ」というタイトルで SaaS on AWS Day 2022 に登壇しました - MOTEX TECH BLOG
アーキテクチャ的には、バージョン2.7 までは、IaaS 上で動くモノリスなアーキテクチャだったのに対し、バージョン3.0 以降では、マイクロサービスとサーバーレスを活用したアーキテクチャへと変化しました。また、このタイミングでクラウド基盤も AWS へと移行しています。
運用面では、バージョン2.7 までは、主に運用チームがインフラの管理を行ってきましたが、バージョン3.0 以降では、開発と運用を一体化したDevOps 体制へと変わりました。機能追加を行うアプリチームが複数あり、各アプリチームの開発者が、インフラ設計から実装・運用まで行うような形です。
バージョン3.0 の運用が始まってから程なくして、マイクロサービス間のデータ連携モジュールにて、性能とコスト課題が発生しました。マイクロサービス間のデータ連携を非同期メッセージングで行っているのですが、初期設計に課題があったために生じており、広範囲にわたって作り変える必要がでてきました。この課題は、サービス利用者が増えるにつれダメージも大きくなるため、早急に解決する必要がありました。
そこで、各アプリチームからメンバーを選出してタスクフォースを組み、対処することになりました。広範囲にアーキテクチャを変更して、この課題は無事解消されたのですが、チーム横断的な課題を解決するチームとして、タスクフォースのメンバー数名が残り、今のインフラチームが出来上がりました。私はその初期メンバーになります。
インフラチームとしての取り組み
マルチアカウント移行
インフラチームとして、次に取り組んだのは、AWS のマルチアカウント構成への移行です。
バージョン3.0 リリース時点では、１つのアカウントで本番・開発を行っていたのですが、よりセキュアで効率的な開発を行うために、マルチアカウント構成（本番・開発環境を AWS アカウントレベルで分ける構成）に変更することになりました。
アプリチームで各マイクロサービスに対して、アプリケーションとインフラにコード修正を行った際、本番環境のアプリケーションやインフラをどう置き換えるかという技術的な部分が課題でリリースできない状況でした。そこで、それらの対応をアプリチームより多少 AWS の知識があったインフラチームが担当することになりました。
本番環境の全てのリソースを構築しなおす必要があり、大変だったのですが、何度かに分けて深夜リリースを行い、結果的に、全てのマイクロサービスをマルチアカウント構成に対応した形へ移行することができました。
この辺りから、インフラチームでは、AWS でのシステム運用には、AWS のサービスに対する詳しい知識が不可欠だという空気が流れ始め、各自、AWS 認定資格を獲るなどしてスキルを身につけ始めます。
コスト削減
その後、暫くインフラチームが取り組んだのは、AWSのサービス利用料の削減です。
LANSCOPE クラウド版 のライセンス毎にかかる AWS のサービス利用料について、ビジネスサイドが考える目標値があったのですが、実際にかかっている利用料は大きく上回っていました。開発チームのタスクとして、なんとか目標値まで近づける必要があり、サービス利用料の削減は、チーム横断で行う施策が多いことから、インフラチームが舵を取って進めることになりました。
実施した施策の一部ですが、以下のようにあらゆる側面から削減できるポイントを見つけて実施しています。
- リザーブドインスタンス や Savings Plans の購入
- 夜間や休日の開発環境のリソース停止
- DynamoDB オンデマンドキャパシティモード適用
- ECS タスク数の Auto Scaling 最適化
- VPC をまとめて NATゲートウェイ の時間あたりの料金削減
- 本番環境での EC2 や ECS のスペック最適化
- 開発環境での無駄なリソースの削除
また、直接削減されるわけではありませんが、本番・開発環境のリソースへのタグ付けも行っています。AWS のサービス利用料を最適化したい場合、幅広いリソースへのタグ付けが有効です。リソース単位での利用料が見えることで、効果的に削減するためのポイントが見えてくるからです。また、開発環境で無駄なリソース起動が行われているといった、事象に気づけるようにもなります。
AWS には、一貫したタグ付けを行うための仕組みがいくつか用意されていますが、LANSCOPE クラウド版 では、コンテナ上で動く自前のプログラムを使ってタグ付けを行っています。
これらの取り組みの成果として、AWS のサービス利用料は、3年間で3分の１まで抑えることができ、目標値もほとんど捉えることができています。
性能改善
続いて、性能改善です。サービスの安定稼働に直結する課題に対しても、取り組んでいます。
例として、デバイスのログや位置情報を表示する機能のバックエンドに、Amazon OpenSearch Service（当時、ElasticSearch Service）を使用していたのですが、表示機能以外にも一括出力機能があり、一括出力が呼ばれたタイミングで、OpenSearch に対して重たいクエリが投げられ、ログや位置情報が表示できなくなってしまう問題がありました。
ログの表示課題を改善するためには、運用負荷も考えると OpenSearch はやめたいという状況でした。なるべく AWS のフルマネージドサービスを使うことで、インフラ管理から解放される方向を目指しており、アプリチームの協力を元に、表示には DynamoDB、一括出力には S3 と Athena というサーバーレスを使った新しいアーキテクチャに置き換えました。
結果として、ログの表示課題は解消され、OpenSearch の管理からも解放され、表示機能にかかる AWS のサービス利用料も10分の１程度まで削減されるといった、１粒で３倍美味しい改修を行うことができました。
運用改善
また、運用改善も行います。
一例ですが、以下、ECS の実行環境を Fargate に移行しています。
LANSCOPE クラウド版 では、ECS も使用していますが、バージョン3.0 リリース時は、Fargate が東京リージョンで GA されていなかったため、EC2 でホストしていました。
ただ、ホストの EC2 インスタンスに関して、以下のような管理作業が発生しており、しんどいなと感じていました。
- OS、ミドルウェアの管理
- 台数管理（タスクが増えたりした際のインスタンス数のスケール作業は手動。。。）
- タスクのデプロイ時に、たまに EC2 へのタスク配置がうまくいかないときがあり、再デプロイしていた
この管理作業から解放されるために、全ての ECS コンテナを、AWS マネージドな実行環境である Fargate へ移行しています。移行作業はとてもスムーズで、移行後も特に問題は発生しておらず、Fargate への移行は正解だったかなと考えています。
さいごに
いかがだったでしょうか？インフラチームとして取り組んできたことは、まだまだたくさんあるのですが、今回は一部のみ、紹介させていただきました。
LANSCOPE クラウド版 では、バージョン3.0 で、モダンなアーキテクチャへと生まれ変わり、運用も大きく変化しています。チーム全体に、AWS やインフラ についての知見があまりなかった中、サービスを安定稼働させていくために、積極的にAWSのマネージドサービスを活用したり、AWS の知識を習得することで対応してきました。
ただ、サービスを改善するためには、まだまだ解決すべき課題が山積みです。一緒に取り組んでいただけるエンジニアを大募集しています。少しでも、LANSCOPE クラウド版 の開発に興味を持っていただけたら、ぜひお気軽にお声がけください！
