名刺データ化システムの前処理サービスをリプレイスしてモダナイズした
by
SansanTech
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
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