こんにちは。みらい翻訳プラットフォーム部のjeffこと川村 です。
もともとバックエンドエンジニアでしたが、最近は SRE に携わっています。

ファイル翻訳の話

今回、AWS Summit Online2020 で紹介された弊社事例を中の人の立場から深掘りして、実際にどういったことを行なっているか皆様に知っていただき、みらい翻訳のことに興味を持っていただければと思います。

まず上記セッションで紹介されたサービスである MiraiTranslator ®︎について紹介します。
弊社で開発・運用している MiraiTranslator®︎ は高い翻訳性能とセキュリティを特徴としている B 向けの機械翻訳サービスです。

その MiraiTranslator ®︎の中でもメインの機能であるファイル翻訳が今回の話の内容となります。
ファイル翻訳はオフィスファイルや PDF などのファイルをアップロードすると自動でファイル内の文章を解析し、翻訳を行ない、最終的に（可能な限り）レイアウトを保持してアウトプットする機能です。
ファイルをそのまま丸ごと翻訳できるのが便利なため、多くのお客様に評価いただいています。ちなみに社内でもファイルを翻訳する際に使用する時が良くあります（笑）

そんなファイル翻訳ですが、アーキテクチャーを少し紹介します。
ファイル翻訳は Docker コンテナで動いてて、オーケストレーションは ECS on EC2 を使用しています。コンテナはステップごとに複数種類あり、それぞれが SQS を通じて処理の連携を行なっています。その他、ファイル置き場に S3 を使っていたり、今回あまり触れませんがファイルアップロードを受け付ける API には API Gateway + Lambda を使用しています。
上記でさらっと解析→翻訳→アウトプットと書いてますが、中では複雑な処理を行なっています。また、ファイルによっては処理にかなり時間がかかる場合があるため以下のようにコンテナを分割して前処理、翻訳処理、ここには書いてないですが後処理と3ステップで行なっています。

『AWS Summit Online　滝口開資氏 発表資料「AWS-27：Amazon EC2 だけじゃない！最高のコスト効率を手に入れるためのスポットインスタンス使いこなし術」P94（https://resources.awscloud.com/aws-summit-online-japan-2020-on-demand-aws-sessions-2-45123/aws-27-aws-summit-online-2020-720p）』より

少し過去の話

今でこそファイル翻訳はコンテナで動いていますが、以前は EC2 に直にアプリケーションを乗せて稼働していました。その時は API とコンテナ化していた前処理、翻訳、後処理のアプリケーションが1つのインスタンスに全部乗っていて、スケールアウト構成にはなっていたものの、全てのアプリケーションが忙しくなくても増えてしまうため、スケール効率はあまりよくありませんでした。また、このときは SQS を使っていたものの可視性タイムアウトと言う機能（後述）を使っておらず、再実行に難がありました（運用で対処していました）。
この状態からコンテナ化できたのはスケールの効率が良くなってコスト効率が上がっただけでなく、運用の手間もかからなくなったため、サービスとしてもプラスになりました。

アーキテクチャの特徴

クラスタで使用している EC2 は全てスポットインスタンスで稼働させています。
スポットインスタンスは通常のインスタンスよりだいたい 70%〜80% オフの価格で使用できますが、いつインスタンスがシャットダウンしてしまうかわからない、または指定したインスタンスの種類のスポットが枯渇していると購入できない、という EC2 の機能です。
商用でこのような不安定な機能を使ってますが、現在大きなトラブルは起こっていません。

全スポットで安定稼働させられているのに2つ工夫しているポイントがあります。一つはミックスインスタンスグループ機能の活用、もう一つは SQS の可用性タイムアウトの活用にあります。

1点目のミックスインスタンスグループ機能はクラスタインスタンスを稼働させている Auto Scaling Group の機能で、クラスタを組むときに複数のインスタンスファミリー＆サイズを指定できるものです。これで複数のインスタンスの種類を指定することでスポットの枯渇にも対応でき、可用性を上げることができています。今のところスポットが買えずにコンテナが動かないというトラブルは発生していません。

2点目の SQS の可視性タイムアウトの活用です。
SQS のキューのメッセージは1回取り出すとメッセージに対する削除 API を実行するまでは再度同じメッセージを取り出すことができます。可視性タイムアウトは同じメッセージを取り出せるようになるまでの時間になります。仮に可視性タイムアウトを 30秒に設定していた場合、メッセージ A を取り出した後に再度このメッセージ A を取り出せるようになるのは 30秒後ということになります。
ファイル翻訳ではキューからメッセージを取り出して処理を行なっています。メッセージを取り出して処理している間はキューから同じメッセージを受け取りたくない（同じメッセージを受け取る＝同じファイルを処理してしまう）ため、可視性タイムアウトを使って処理中は同じメッセージを受け取れないように防いでいます。
また、もしスポットインスタンスが突然落ちて処理途中でコンテナが落ちてしまっても可視性タイムアウトが過ぎればまた同じメッセージを受け取れるため、処理を継続することが可能となっています。
この機能を使うのを考えたときに懸念したのが、ファイル翻訳の処理時間が読めない点でした。処理時間が読めないため可視性タイムアウトを長い方に合わせれば安全ですが、そうすると同じメッセージを読み取れるようになるまでの時間が長くなってしまい、再実行まで時間がかかってしまいます。そこも AWS は考慮していたのか、可視性タイムアウトを延長する API が用意されています。ファイル翻訳処理のプログラム内で可視性タイムアウトを延長する処理を入れることで、ベースのタイムアウト時間は短く（すぐに再実行できる）かつファイル翻訳処理時間に関係なく可視性タイムを指定できる（延ばせる）ことを実現できています。

『AWS Summit Online　滝口開資氏 発表資料「AWS-27：Amazon EC2 だけじゃない！最高のコスト効率を手に入れるためのスポットインスタンス使いこなし術」P102（https://resources.awscloud.com/aws-summit-online-japan-2020-on-demand-aws-sessions-2-45123/aws-27-aws-summit-online-2020-720p）』より

最後に

このほか、コンテナを素早くスケールアウトさせてファイル翻訳処理が詰まらないように Lambda でスケール処理を仕込むなど行なっているなど色々工夫点はあります。
また、Fargate Spot の検証やさらなるスケールインアウトの高速化、モニタリングや抜本的なアーキテクチャの見直し（！）などやりたいことはまだまだたくさんあります。
この記事を読んでみて「自分も携わってみたい」「こういう風に良くしていきたい」など興味を持っていただければ幸いです。ぜひ一度お話をさせていただければと思います。