事業の根幹を担うデータ化システムのインフラのこれまでとこれから / The past and future of infrastructure of the digitization system supporting the foundation of our business

事業の根幹を担うデータ化システムのインフラのこれまでとこれから Sansan株式会社 DSOC 技術本部サービス開発部 Infrastructure Group 藤田斉
2021.08.11 EngineeringTeamPresentation

Data Strategy and Operation Center アジェンダ・ゴール 1 • アジェンダ •
Sansanについて • DSOC、インフラチームについて • 事例紹介 > CloudSearch移行 > ログイン承認制 > GEESのコンテナ化 • 今後の課題 • ゴール • 事例・TIPSを共有し、どこかで皆様のお役に立てば嬉しいです

Data Strategy and Operation Center 自己紹介藤田斉 Hitoshi Fujita
Sansan株式会社技術本部サービス開発部 Infrastructure group • 前職では独立系SIerで主に金融系のインフラ構築に従事 • 2018年にSansan株式会社へ入社 • DSOCが提供する各種サービスのインフラ構築・運用を担当 • 趣味はバスケットボールとTVゲーム

Data Strategy and Operation Center Sansan株式会社が展開する3つの事業クラウド名刺管理サービス名刺アプリクラウド請求書受領サービス

Data Strategy and Operation Center 組織構成ビジネス統括本部 Sansan株式会社データ統括組織プロダクト組織
技術本部研究開発部(R&D) データ分析・研究開発（画像処理／機械学習・AI）サービス開発部システム開発・データマネジメント EBPM支援室客観的エビデンスの活用を支援データ戦略室データ活用戦略の立案や新規事業の企画・開発

Data Strategy and Operation Center z DSOC サービス開発部名刺データ化名寄せ
ニュース配信三三太郎 Yonyon 株式会社三三太郎 Sansan 株式会社 Bill One Entry グループ Naoyse グループデータ化グループ Infrastructure グループ Data Management グループ請求書データ化契約書データ化

CloudSearch移行

Data Strategy and Operation Center 背景、課題 7 背景 • データ化された名刺情報のアーカイブ先として元々Amazon
CloudSearch を利用 • 気がつけばクリティカルなユースケースも増え重要なサービスに課題 • シングルAZ構成で稼働 • AWS費用が凄い • リソース拡張がコントロールできない

Data Strategy and Operation Center Amazon Elasticsearch Serviceへ移行 8 選定理由
• 一番クリティカルなユースケースに全文検索利用したい移行 • CloudSearchとElasticsearchの両方に書き込み • 並行して既存データをバッチ処理でElasticsearchに書き込み • 既存データの更新は上記バッチ処理が完了後に適用 • インスタンスサイズ、ノード数、レプリカ数は様子を見ながら調整 • インスタンスサイズもBlue/Greenデプロイメントで変更可能成果 • 可用性の向上 • 大幅なコスト削減 • クライアント側に性能劣化無し

ログイン承認制 ※恐れ入りますが本パートの資料は非公開とさせていただきます

名刺データ化システムのコンテナ化

Data Strategy and Operation Center 名刺データ化システムとは 11 マイクロタスク×マルチソーシングによる独自の名刺データ化システム

Data Strategy and Operation Center システム構成 12 サービス構成 • 各プロセスをサービスに切り出し、それぞれWebAPIと複数の非同期ワーカーで構成
• 非同期ワーカーはSidekiqキュー、SWFキュー、データベースから読み込み • バッチ処理などのスケジュール実行はRundeckで制御インフラ構成 • EC2で稼働 > Webサーバ, Batchサーバ, 管理Webサーバ, etc... • 1台のBatchサーバには複数サービスのワーカーが配置される > ワーカー数は独自に開発した管理ツールで運用技術スタック • Ruby on Rails • EC2, RDS, S3, ElastiCache, Elasticsearch, SWF, etc…

Data Strategy and Operation Center ワーカー運用の課題 13 ① 空きリソースを確認ワーカー
管理ツール ② 指定したホストに手動で追加 EC2 Instance EC2 Instance EC2 Instance Worker 1 Worker 3 Worker 3 Worker 3 Worker 2 Worker 2 Worker 1 Worker 4 Worker 4 Worker 4

Data Strategy and Operation Center ワーカー運用の課題 14 ① 空きリソースを確認ワーカー
管理ツール ② 指定したホストに手動で追加 EC2 Instance EC2 Instance EC2 Instance Worker 1 Worker 3 Worker 3 Worker 3 Worker 2 Worker 2 Worker 1 Worker 4 Worker 4 Worker 4 ワーカーをコンテナ化、オートスケーリングで運用負荷を減らしたい！

Data Strategy and Operation Center 実装のポイント 15 • コンテナ管理 •
データプレーン • オートスケーリング • スケジュール実行 • デプロイ管理 • Rails Console

Data Strategy and Operation Center コンテナ管理 16 ECS • パワフル&シンプル
EKS • オープン&フレキシブル引用: https://www.slideshare.net/AmazonWebServicesJapan/202106-aws- black-belt-online-seminar-con120-aws-249613877 ECSを選定 • Kubernetesでしか達成できないことが無かった • 半年期に一回のアップデートに追従できるリソースが無かった

Data Strategy and Operation Center データプレーン 17 Fargate • インスタンスの管理不要
• EC2に比べてよりセキュアな実行環境 EC2 • CPU/MEMの組み合わせに制限なし • GPUの利用が可能 EC2を選定 • サービス毎に性能要件にばらつきがあり、Fargateでは大幅にコスト増 • Scheduled TaskではFargateを採用 • Capacity Providerを利用することでインスタンス管理コストを低減

Data Strategy and Operation Center オートスケーリング 18 コンテナ • Target
Tracking Scaling > 時間あたりの目標処理量が決まっているもの > WebAPI（リクエスト数） • Step Scaling > 常にキューが0の状態を目指すもの > 非同期ワーカー（Sidekiq、SWF） • SidekiqのキューはECS Scheduled Taskでカスタムメトリクスに登録 EC2 • Capacity Providerで必要なコンテナ数に応じて自動的にスケールアウト

Data Strategy and Operation Center オートスケーリング 19

Data Strategy and Operation Center スケジュール実行 20 ECS Scheduled Taskをecscheduleで管理
• Scheduled Taskの実態はEventBridgeからECSタスクの実行 > EventBridge、ECSタスク定義それぞれ管理が必要 > アプリケーションのライフサイクルに依存するためTerraformではミスマッチ • 設定管理はecscheduleを利用、ジョブ構成をGitHub上で管理可能に > https://github.com/Songmu/ecschedule • 適用はデプロイパイプラインに組み込み

Data Strategy and Operation Center デプロイ管理 21 CodePipeline + CodeBuild
+ ecs-cliで実装 • CodePipeline/CodeBuild > 複数アプリケーションの同時デプロイをコントロール > 手動承認をAPI Gateway + LambdaでSlackから • 現在ならSlackのSocket Modeを利用することでFargateで置き換えれそう • https://slack.dev/python-slack-sdk/socket-mode/index.html > CodeBuildで各サービスごとにecs-cliでデプロイ • ecs-cli > AWS公式かつ、docker-composeと互換性あり採用 • ほとんど更新されていないので今から使うのはおすすめできない > 今からであればecspressoがおすすめ • https://github.com/kayac/ecspresso > シンプルな構成であればそもそもCLIツールは不要

Data Strategy and Operation Center デプロイ管理 22

Data Strategy and Operation Center Rails Console 23 背景 •
調査、障害対応などでRails Consoleを利用することがある • アプリケーションのと同じコンテナイメージを使いたい • アプリケーションコンテナに `docker exec` するのはシステム影響を考慮して避けたい。また、本番稼働に不要なツールを配置したくない対応 • アプリケーションコンテナとは別にRails Console用コンテナを作成 • 起動スクリプトで必要なツールをコンテナ起動時にインストール • EFS、S3を利用して一時ファイルの保管場所を準備

Data Strategy and Operation Center Rails Console 24

Data Strategy and Operation Center 実装のまとめ 25 • コンテナ管理、データプレーン •
エンジニアリソース、サービス毎の特性を考慮して ECS on EC2を採用 • オートスケーリング • コンテナはそれぞれの特性に合わせ、EC2はCapacity Providerを利用して実装 • スケジュール実行 • ECS Scheduled Task + ecscheduleでジョブ構成をGitHubで管理可能に • デプロイ管理 • CodePipeline + Codebuild + ecs-cliで承認を組み込んだデプロイを実装 • Rails Console • 独立したECSサービスとして準備

Data Strategy and Operation Center 運用してみての課題 26 • Capacity Providerのスケールイン
• 課題： 1つでもタスクが残っているとインスタンスがスケールインできない • 対策：リソース使用率の低いEC2をドレインさせる仕組みが必要(未対応) • コンテナのOut Of Memory • 課題：稀にワーカーでOut Of Memory、メモリ使用率が上昇し続ける事象も • 対策： EC2でSwapを有効化、定期的にワーカーを再起動(ワークアラウンド) • AWSコンソールが使いづらい • 課題： 1クラスタあたりのサービスが増えると管理が難しい

Data Strategy and Operation Center インフラチームで今後やりたいこと 27 • Elasticsearchの分割 •
Terraform化の促進 • ログ基盤の刷新 • 統合アカウント基盤の構築 • and more...

We are hiring！新規事業開発新規事業開発エンジニアウェブアプリケーションエンジニア PdM（プロダクトマネージャー）社内システム開発コーポレートエンジニアセキュリティーエンジニア
（SOC、社内教育・監査） DSOC / 研究開発インフラエンジニア自然言語処理研究員社会科学分野研究員機械学習研究員 OCR開発技術者 R&D DevOpsエンジニアデータエンジニアサービス基盤エンジニアデータサイエンティストサービス開発サービス開発エンジニアウェブアプリケーションエンジニアインフラエンジニア iOSエンジニア Android エンジニア SETエンジニアブランディング・マーケティングフロントエンドエンジニア募集中のポジション詳細はこちらから https://jp.corp-sansan.com/recruit/midcareer

事業の根幹を担うデータ化システムのインフラのこれまでとこれから / The past and ...

事業の根幹を担うデータ化システムのインフラのこれまでとこれから / The past and future of infrastructure of the digitization system supporting the foundation of our business

Builders Box

More Decks by Builders Box

Other Decks in Technology

Featured

Transcript

事業の根幹を担うデータ化システムのインフラのこれまでとこれから Sansan株式会社 DSOC 技術本部サービス開発部 Infrastructure Group 藤田斉

Data Strategy and Operation Center アジェンダ・ゴール 1 • アジェンダ •

Data Strategy and Operation Center 自己紹介藤田斉 Hitoshi Fujita

Data Strategy and Operation Center Sansan株式会社が展開する3つの事業クラウド名刺管理サービス名刺アプリクラウド請求書受領サービス

Data Strategy and Operation Center 組織構成ビジネス統括本部 Sansan株式会社データ統括組織プロダクト組織

Data Strategy and Operation Center z DSOC サービス開発部名刺データ化名寄せ

CloudSearch移行

Data Strategy and Operation Center 背景、課題 7 背景 • データ化された名刺情報のアーカイブ先として元々Amazon

Data Strategy and Operation Center Amazon Elasticsearch Serviceへ移行 8 選定理由

ログイン承認制 ※恐れ入りますが本パートの資料は非公開とさせていただきます

名刺データ化システムのコンテナ化

Data Strategy and Operation Center 名刺データ化システムとは 11 マイクロタスク×マルチソーシングによる独自の名刺データ化システム

Data Strategy and Operation Center システム構成 12 サービス構成 • 各プロセスをサービスに切り出し、それぞれWebAPIと複数の非同期ワーカーで構成

Data Strategy and Operation Center ワーカー運用の課題 13 ① 空きリソースを確認ワーカー

Data Strategy and Operation Center ワーカー運用の課題 14 ① 空きリソースを確認ワーカー

Data Strategy and Operation Center 実装のポイント 15 • コンテナ管理 •

Data Strategy and Operation Center コンテナ管理 16 ECS • パワフル&シンプル

Data Strategy and Operation Center データプレーン 17 Fargate • インスタンスの管理不要

Data Strategy and Operation Center オートスケーリング 18 コンテナ • Target

Data Strategy and Operation Center オートスケーリング 19

Data Strategy and Operation Center スケジュール実行 20 ECS Scheduled Taskをecscheduleで管理

Data Strategy and Operation Center デプロイ管理 21 CodePipeline + CodeBuild

Data Strategy and Operation Center デプロイ管理 22

Data Strategy and Operation Center Rails Console 23 背景 •

Data Strategy and Operation Center Rails Console 24

Data Strategy and Operation Center 実装のまとめ 25 • コンテナ管理、データプレーン •

Data Strategy and Operation Center 運用してみての課題 26 • Capacity Providerのスケールイン

Data Strategy and Operation Center インフラチームで今後やりたいこと 27 • Elasticsearchの分割 •

We are hiring！新規事業開発新規事業開発エンジニアウェブアプリケーションエンジニア PdM（プロダクトマネージャー）社内システム開発コーポレートエンジニアセキュリティーエンジニア