事業の根幹を担うデータ化システムの インフラのこれまでとこれから 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

No content