こんにちは、元 Typetalk チームの永江です。(現在は Backlog Git チームに所属)
今回は Typetalk のエクスポート機能開発の裏側について書いていこうと思います。

はじめに

残念なことに Typetalk はサービス終了が決まり、2025年12月1日以降は、これまでに投稿されたメッセージやファイルなどを見ることができなくなります。
そのため、今まで Typetalk をお使いいただいたユーザー様ができるだけ困らないようにサポートする意図でエクスポート機能を開発しました。

Typetalkに投稿した内容の「エクスポート機能」をリリースしました

エクスポート機能には以下の3種類のエクスポート方法があります。

1. トピック / DM エクスポート
2. ボット一覧エクスポート (管理者のみ)
3. トピック一括エクスポート (管理者のみ)

今回はトピック一括エクスポートの開発で検討した3つのポイントを紹介します。

ポイント1 – アーキテクチャ設計

まず1つ目のポイントはシステム全体のアーキテクチャ設計についてです。

検討

アーキテクチャ設計するに当たり、以下の3つの案を考えました。

1. Typetalk (EC2 上で動いている Web アプリケーション) のみで完結
   1. Typetalk 内にエクスポート機能を追加
2. Typetalk → SQS + Lambda
   1. Typetalk から SQS 経由で Lambda にリクエストする
   2. Lambda でエクスポートプロセスを実行する
3. Typetalk → Step Functions + Lambda
   1. Typetalk から Step Functions にリクエストする
   2. エクスポートプロセス全体を Step Functions ワークフローとして定義する
   3. Lambda を Step Functions ステートマシンとして設定する
   4. Lambda でエクスポートプロセスを実行する

次に、それらの構成案を以下の3つの観点で比較・検討しました。

1. エクスポート機能実行時の負荷が、Typetalk のチャット機能の利用に影響を与えないようにする
2. 組織単位 / トピック単位で容易にエラーハンドリングできるようにする
3. 処理単位でパフォーマンスの調整が容易にできる

1. Typetalk
   1. × : エクスポート処理は同一リソースを使用して実行されるため、システム負荷が集中し、他の機能が正常に動作しない可能性がある
   2. ×：エラー処理が難しく、開発コストが高い
   3. ×：パフォーマンスチューニングが難しい
2. Typetalk → SQS + Lambda
   1. ○：リソースを分離できるため、システム負荷が分散され、他の機能の動作に影響を与えない
   2. △：Lambdaごとのエラー処理は簡単だが、エクスポート処理全体のエラー処理には工夫が必要で開発コストが高額になる
   3. △：Lambdaごとのパフォーマンスチューニングは容易ですが、エクスポートプロセス全体のパフォーマンスチューニングは困難
3. Typetalk → Step Functions + Lambda
   1. ○：リソースを分離できるため、システム負荷が分散され、他の機能の動作に影響を与えない
   2. ○：エラー処理が容易で開発コストが低い
   3. ○：ワークフロー / Lambdaごとにパフォーマンスチューニングが容易

結論

以上のことから3つの観点を満たしている、Typetalk → Step Functions + Lambda を選択しました。

ポイント2 – Lambda の実行時間制限

2つ目のポイントは、Lambda の実行時間制限についてです。

課題

ポイント1で決定した通り、Step Functions + Lambda で以下のようなワークフローを作成しました。

1. Lambda: A
   1. 組織に紐づくトピックの ID を取得する
2. Lambda: B
   1. トピック ID からトピックに紐づくデータを取得する
   2. 取得したデータからファイルを作成し、S3 にアップロードする
3. Lambda: C
   1. S3 からファイルをダウンロードする
   2. ダウンロードしたファイルを圧縮して、再度 S3 にアップロードする

しかし、ワークフローを何度か動かしていると、Lambda: C の処理がエラーになるケースがありました。
原因を調査したところ、メッセージ数の多いトピックを持つ組織の場合ファイル容量が大きくなり、S3 からファイルをダウンロードするのに時間がかかっている事がわかりました。
Lambda には最大 15 分の実行時間の制限があり、処理時間が長すぎてタイムアウトしていたのです。

Lambda は、コードを一定時間実行してからタイムアウトします。タイムアウトとは、Lambda 関数がタイムアウトするまでの最大実行時間です。この設定のデフォルト値は 3 秒ですが、最大値の 900 秒 (15 分) まで 1 秒単位で調整できます。

参照: Lambda 関数のタイムアウトを設定する

検討

この課題を解決するために、3つのアーキテクチャ変更案を考えました。

1. Glue Job / S3
   1. Lambda を Glue Job に変更する
2. Lambda / Dynamo DB
   1. S3 を Dynamo DB に変更する
3. Lambda / EFS
   1. S3 を EFS に変更する

次に、それらの構成案を開発コスト、処理性能の観点で比較・検討しました。

1. Glue Job / S3
   1. ×：変更コストが高い
      1. プログラミング言語を変更する必要がある (Typescript → Python または Scala)
      2. 導入経験がないため、システム構築に時間がかかる
   2. ×：実行時間制限をなくすことでエラーは回避できるが、プロセス自体のパフォーマンスは向上しない
2. Lambda / Dynamo DB
   1. ×：変更コストが高い
      1. データ形式を変更する必要があり、修正する部分が多い
      2. 経験不足のため構築に時間がかかる
   2. ○：S3 よりも高速なのでパフォーマンス向上が期待できる
3. Lambda / EFS
   1. ○：変更コストが低い
      1. AWS の機能として Lambda の共有ストレージとして指定できるため、プログラムの変更を最小限に抑えることができる
      2. システムがすでに実装されているため、構築する必要がない
   2. ○：EFS を Lambda の共有ストレージとして設定することができ、その結果ダウンロード処理自体が不要となり、全体の実行時間が短縮される

結論

以上のことから、2つの観点を満たしている Lambda + EFS を選択しました。

ポイント3 – データベースのボトルネック

最後のポイントは、データベースのボトルネックについてです。

課題

Step Functions + Lambda を使うことでプログラムレベルでの分離はできたのですが、データベースレベルではまだ既存機能とリソースを共有していました。
そのため、大きなトピックのエクスポートを実行した際に既存機能の動作が重くなる懸念がありました。

• 既存の構成

• エクスポート機能追加後の構成 (既存のエンドポイントをエクスポート機能でも使っている)

検討

そのため、エクスポート機能専用のリーダーインスタンスを追加し、既存機能とリソースを分離することを考えました。

しかし、その場合エクスポートを使っていないときにリソースが無駄になることが懸念事項にありました。

• RI (リザーブドインスタンス) のため、できるだけリソースは活用したい
• 既存機能の DB 負荷が時折高くなることがあったため、リスクヘッジしたい

結論

エクスポート機能の通信は追加リーダーインスタンスのみに流しつつ、既存機能の通信は追加リーダーインスタンスにも流して負荷分散するようにしました。

• エクスポート機能の負荷は既存機能に影響しない
• 既存機能の負荷を分散できる

おわりに

以上、Typetalk のエクスポート機能の開発で考慮した3つのポイントでした。
サービスを終了するための機能提供というところで、Typetalk チームメンバーとしては複雑な心境での開発でしたが、議論を重ね、良い設計・実装ができたと思っています。

また、これまで Typetalk をお使いいただいた皆様にこの場を借りてお礼申し上げます。
ありがとうございました。