名刺データ化システムの前処理サービスをリプレイスしてモダナイズした

■イベント


【Sansan Tech Meetup】インフラエンジニアが考えるプロダクトと組織
https://sansan.connpass.com/event/287609/

■登壇概要

タイトル：名刺データ化システムの前処理サービスをリプレイスしてモダナイズした

登壇者：技術本部 Digitization部 Infrastructureグループ　福田 隆誠





■Sansan 技術本部 採用情報

https://media.sansan-engineering.com/

Transcript

1. Sansan技術本部 名刺データ化システムの 前処理サービスをリプレイスして モダナイズした Digitization部 Infrastructureグループ 福⽥隆誠
2. 写真が入ります 福⽥ 隆誠 Sansan株式会社 技術本部 Digitaization部 Infrastructureグループ - 2020年に新卒でSansan株式会社に入社 - Digitization部の各システムのインフラを担当
3. - 名刺データ化技術について - 名刺の前処理システムの概要 - リプレイス前の名刺の前処理システムの課題 - リプレイス内容 - リプレイス詳細 - リプレイスの効果 - まとめ アジェンダ
4. 名刺データ化技術について マイクロタスク×マルチソーシングによる独⾃の名刺データ化システム。 4 分類した名刺情報の切⽚化 3 名刺項⽬の分類 1 2 スキャン・撮影 画像処理 5 データ⼊⼒ 本⽇はこのステップが担当する 前処理システムについてお話します
5. - 名刺画像を「補正」する処理 - 4点切り取り補正 - 画像回転 - ホワイトニング 名刺の前処理システムの概要 Eight ELB ELB APIサーバ Webサーバ バッチサーバ データベース ELB ELB APIサーバ Webサーバ バッチサーバ データベース Sansan
6. - 各工程で起きた問題の把握に手間がかかっていた - 名刺画像補正失敗の監視が複雑だった - バッチサーバーとDBで各工程の状態を管理 - 失敗時のリカバリ方法も手間がかかっていた - サーバにログインしてアプリケーションログを確認して個別に対応 - データ化をとめずにデプロイするのに手間がかかっていた - 各サーバにログインし、アプリケーションの差し替えが必要 - Web・APIサーバはロードバランサの切り離しが必要 - EC2インスタンスのメンテナンス対応が必要だった - OSのバージョンアップ・リタイアメント対応などが必要 - インフラもコード化されていなかった - ロードバランサ等のインフラリソースの設定変更は手動 前処理システムの課題
7. - マネージドサービスを駆使して、画像補正のワークフローを構築した - アプリケーション内の各処理を独立したサービスとして分割した - サービス観点の監視に変更した - コンテナ化してECSを利用することでデプロイを簡略化 - 運用・管理コストが低いインフラを構築した - Fargate で運用レスな構成を構築した - 構成管理ツールでインフラの管理を簡易化した リプレイス内容
8. 前処理システム リプレイス後の構成 SNS + SQSでワークフローを構築 各工程の状態はDBに保存 Terraformで インフラのコード化 SQS SNS SNS SNS SNS 受け取りサービス オーケストレーションサービス Aurora 自動回転 • 受け取りサービス 納品サービス SQS SQS SQS ホワイトニングサービス バッチサーバ内の各工程を ECSサービスとして独立させ 動作環境にFargateを採用 1 2 3
9. 画像補正のワークフローについて - SQSを利用し、 オーケストレーションサービスを 実装してワークフローを実現 - 基本的に番号の順に工程が進む - オーケストレーションサービスは データ状況に基づき適切な処理に 振り分ける - 各SQSのキューの前段に SNSを配置 - 拡張性をあげるため 1: 受付 2,4,6: オーケストレーション 3: 自動切り取り 回転 どこまで進んだか保存する 5: ホワイトニング 7: 納品
10. - デプロイ - 各サービスが疎結合になったので、個々のサービスを独立してデプロイ可能になった - 前処理システムを停止せずともデプロイ可能になった - 監視 - サービス観点の監視が簡易化された - 前）アプリケーション内に、都度データ化状況を通知する処理が含まれていた - 後）SQSに溜まっているキューの中で最も古いメッセージ （ApproximateAgeOfOldestMessage）を監視 - 各工程はキューに積まれるため、工程毎のキューを監視すればボトルネックの箇所を特定できる - 各工程の処理失敗検知 - アプリケーションが正しく処理できない場合、メッセージはDLQにキューイングされるため、 DLQ内のメッセージの数を監視することで、問題が発生した工程を簡単に把握できる ワークフロー実装による運⽤効率と監視能⼒の強化
11. - EC2インスタンスの管理から解放された - 定期的に来るWindowsアップデートやメンテナンス対応も不要になった - 調査専用コンテナを用意した。このコンテナにログインして運用作業する - Amazon ECS Exec でコンテナにログインできるようにした - ECSサービス以外は全てTerraformで管理するようした - アプリケーション開発者もTerraformを書いて、レビューする文化にした - 設定レベルで開発者と認識合わせられるようになった - ※ ECSサービスはデプロイツールで管理 運⽤・管理コストが低いインフラを構築
12. - 名刺の前処理システムをリプレイスした - マネージドサービスを駆使して、画像補正のワークフローを構築した - 運用・管理コストが低いインフラを構築 - 今後 - FargateSpot + オートスケールの構成にしていく - 突発的な名刺データ化依頼への対応 - コスト最適化 まとめ