オンプレミスで動くアプリケーションを SaaS へ移行させる際のよもやま話 ~前編 : SaaS 移行の事始め

とはいえ、サイロモデルには「隔離」の点でメリットもありました。
ここでいう「隔離」とは、

• データの隔離
  複数のテナント間における「データ」の隔離を行うこと。本製品の場合は、各テナントから収集した監査ログの保存などがこれにあたります。セキュリティインシデントの発生を防ぐ事、データストレージの利用量などをテナントで分離する事等が目的にあげられます。

• プロセスの隔離 
  ノイジーネイバーにみられる、「各テナントにおけるプロセス負荷のばらつき」から発される問題を分離します。また各テナントのプロセスが分離することにより、課金などの処理を行う際の各テナントの集計が容易になるとも考えました。

このような「サイロモデル」におけるメリットも享受したいという所から、私たちはオンプレミス版の構造を整理し、クラウド上でどのような構成にしていけばよいのか ? という所から考えはじめました。

オンプレミス版の本アプリケーションはざっくりと以下のコンポーネントで構成されています。

• Web サーバー
  従前の Web アプリケーションに見られる一般的な形をしており、本体が起動すると同時に Web サーバーとして動作をします。そして、その内部では下記ビジネスロジックをホストしています。

• ビジネスロジック (WebAPI)
  本記事では所謂 WebAPI (アプリケーション層) を総じてビジネスロジックと称します。これは後述の「バッチタスク」との色分けを行う為です。主に永続層へのデータの読書き、あるいはバッチタスクを動作させるためのトリガーや軽微な前・後処理などが該当します。

• 永続層 (アプリケーション設定ストア)
  アプリケーション動作時に必要な設定群、あるいはアプリケーションログ (ユーザー操作・プロセス動作・統計情報) などを保存する層を指します。この層で扱うデータ群はビジネスロジックで読み書きされ、バッチタスクの中で実行コンテキスト (バッチの設定入力) として扱われたりします。

• バッチタスク (収集、変換、レポート作成処理等)
  ALog ConVerter では上記ビジネスロジックとは別に、コンカレントにバックグラウンドで動作するプロセスとして、バッチタスクが存在します。厳密にはこれもビジネスロジックの一つではあるのですが、上記に挙げるビジネスロジックのようにプレゼンテーション層とのつなぎとして動作する軽微なロジックとは異なり、収集・変換・レポート作成処理等に見られる、処理に時間がかかり、処理データ量も多いプロセスを指します。この部分が製品のプロセスマジョリティとなっています。

• ログ検索エンジン
  上記バッチタスクと比類して、収集した監査ログの検索・レポート作成を行う事に特化された検索エンジンです。これも上記のビジネスロジックとは異なるインスタンスとして動作します。本エンジンはビジネスロジックやバッチタスクから利用されます。

• データストレージ (監査ログファイル群)
  各サーバーやサービスから取得した監査ログ、あるいはサービスの出力結果等を保存する層になります。広義的には永続層ですが、本記事では上記永続層とは意味合いが異なりより純な「データストレージ」としての役割を指します。

オンプレミス版では、これらコンポーネントは 1 つのサーバーマシンで混然一体となって動作しています。SaaS 版で重要だったのは、この構成中のどのコンポーネントが「マルチテナント化において分離が必要なのか ?」という点でした。そこで私達は以下のように、処理内容・処理量で大まかに 2 つのブロックに分離するようにしました。

• 処理内容が軽い・データ量が少ない

  • WebAPI で処理される簡易な処理

  • 永続層へのアプリケーションパラメータの書き込み

• 処理内容が重い・データ量が多い

  • バッチタスク (収集処理、変換処理、レポート作成処理等)

  • ログ検索エンジン (検索処理、レポート作成処理の内部集計処理)

  • データストレージ (監査ログファイル群・サービスの出力結果)

「処理内容が重い・データ量が重い」部分に関しては、複数アカウント (テナント) にて実行時間・処理量が違う為「プロセスの分離」をする必要性、またユーザーからお預かりする機密対象のデータとそのデータの保存量の大小を勘案し「データの分離」をする必要性があったからです。その他のいわゆる Web サービスの部分などの「処理内容が軽い・データ量が少ない」部分に関してはプールモデルを採用しプロセスの集約を行う事で、そのメンテナンスも簡便になると踏んだのです。

上記の分離における管理・企業のプロセスに対して、AWS のアカウントを割り当てています。この利点は、各 AWS サービスのクォータ (利用制限) をアカウント毎で緩和しやすい事 (もしプールモデルであればシステム全体で 1 アカウントのクォータが適応されてしまうため)、データ分離における「システム的・セキュリティ的境界線」をイメージしやすくなる事が挙げられます。

今回私たちは、プールモデルでプロセスを共通化した部分を「管理アカウント」とし、サイロモデルのように各テナント部分を「企業アカウント」とデザインをしました。

当初、トランザクションの有無や、クエリの移行のしやすさから RDS を永続層に採用しようとしていました。しかし、サーバーレスを中心とした多量のサービスプロセスが発行されるサービス設計にした場合、従来の RDB では永続層の読み取りキャパシティが耐えきれなくなる問題が発生しました。

具体的には、例えば変換処理の並列度を 100 とか 200 とかいうオーダーで同時発生させたときに、変換処理用のパラメータの同時読み込みが多量発生するなど、当初予想していた Read キャパシティーよりも早く上限を打っていたのです。RDS 自身の設定で Read キャパシティーを増やす事も可能なのですが、今後もこの類の処理はスケールする事が求められる為、私たちは永続層のインフラとして Amazon DynamoDB を再選定する事にしました。もちろんこの決定は容易ではなく、従来のトランザクションに付随する問題は DynamoDB の特性を活かした方法へ昇華する必要があります。しかし、今回置き換えた部分は、主にアプリケーションパラメータに見られる「1 データ量は少ないが、大量の読み込みを迫られる」事が予想されるため、今後スケールさせる事を考えると RDS に比べ話が進めやすいと判断したのです。

Webサーバーによるビジネスロジックバッチタスクを Lambda で作成したのですが、意外と Lambda にも制約が多い事に気が付き始めます。特に以下のような制約において、苦慮する事となりました。

• 実行時間の制約
  Lambda には実行時間の制約があります (この原稿を書いている時点で 15 分)。 私たちのログ変換処理では、コンテキストの詳細な解析なども行うため、ログの大きさによってはこの 15 分をゆうに超えるケースも存在し、これが原因でタイムアウトを起こすこともしばしばありました。

• メモリの制約
  Lambda では実行時利用できるメモリ (10GB) に上限があります。 変換処理などは高速化の為、収集したログに応じて積極的にメモリを使う作りになっており、これもまた足かせとなりました。

• ストレージ領域の制約
  本プロジェクトの初期の段階で Lambda ではデフォルトで 512 MB の容量しかありませんでした。これを超える「一時的なファイル」などを作りたい場合には Amazon EFS などのストレージサービスを別途使わなければなりません (本稿を書いている時点で、10 GB に拡張できるようになったようです。AWS は日々進化していますね)。

このような制約があったため、Lambda で作っていたバッチタスクを Amazon ECS / AWS Fargate 化することで問題回避しました。また、Fargate 化することにより、管理アカウント上にある Amazon ECR をうまく使う事で「アカウントをまたいだプログラムのデプロイが一極集中で簡単になる」という良い副作用の恩恵を受けることになります (コンテナイメージを管理アカウント配下で管理し、そのイメージを複数の企業アカウントで取得実行するといった具合です)。