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