AWSを活用した機械翻訳のための GPU並列処理環境の構築 ストックマーク株式会社 バックエンドエンジニア　麻生 晋併 2021/06/16

ストックマークのプロダクト：「Anews」 ● 国内外30,000メディアの記事を毎日収集 ● 最先端の自然言語処理で個人や組織のミッションに即した記事をレコメンド

レコメンドの課題：英語記事の配信精度の向上 ● ユーザーの過去記事へのアクションから当日配信する記事を選定 ● 英語記事は読まれない → 精度が上がらない → 読まれないまま... 読むのが大変なので 精度が高くないなら 読みたくない。

解決策：日本語記事の行動履歴の活用

翻訳のためのインフラ見直し（現状：EC2インスタンス1台） POINT1：翻訳用のGPU並列処理環境の追加 ● 翻訳はGPU環境を複数用意して並列処理しないと処理時間がかかりすぎる POINT2：既存処理環境(CPU環境)と翻訳処理環境(GPU環境)の分離 ● GPU不要の既存処理をGPU環境で実行するとコストがかかりすぎる POINT3：ワークフローエンジンの導入 ● サーバを跨いだワークフローの管理が必要

インフラ選定結果 翻訳処理環境(GPU環境)：AWS Batch + Amazon EC2 ● GPUを利用可能、かつ、配列ジョブで並列処理を実装しやすいことからを採用 ● 並列数を記事数に応じて変えるため、事前に Lambda で必要な並列数を算出 既存処理環境(CPU環境)：Amazon ECS + AWS Fargate ● EC2は他サービスと連携しづらいため既存処理環境も差し替え ● 既に一部タスクを ECS + Fargate で実行できる状態にしていたので他タスクへ拡張 ワークフローエンジン：AWS Step Functions ● AWSサービスとの連携しやすさ＋社内での利用実績から採用

インフラ構成ビフォーアフター

ストックマークのテックブログで もう少し詳しく解説しています https://tech.stockmark.co.jp/blog/gpu_translate/

インフラ再構築のポイント Infrastructure as Code (IaC) ● コードで書いてある通りにインフラの追加・削除・変更が可能　 → 開発環境で試行錯誤しやすい、本番環境反映時の負担軽減とミス防止 ● コードが設計書としても機能する → 引き継ぎしやすい CI/CD ● GitHub で特定のタグを付与すると CodeBuild で自動デプロイ用のワークフローが実行され る（CPU/GPU環境別のイメージのbuild&push、ECSとBatchの定義更新） → 開発環境/本番環境へのデプロイ時の負担軽減とミス防止

【6月29日（火）19:30開催！】
 　
 Stockmark Tech Meetup #1
 　
 テックブログで語られなかった試行錯誤の数々を公開！
 https://stockmark.connpass.com/event/216396/