Slide 1
Slide 1 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
カヤック・アンドパッド 合同 プロポーザル供養会 2023/12/04
Ruby on Rails + Sidekiq構成のモノリ
シックサービスをコンテナ化した話
株式会社アンドパッド開発本部 SRE
角井 暖
1
Slide 2
Slide 2 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
このセッションでお話すること
2
Ruby on Rails + Sidekiq構成のモノリシックサービスをコンテナ化した話 |
CloudNative Days Tokyo 2023
● ANDPADとSREチームの紹介
● なぜコンテナ化したのか
● コンテナ化の泥臭い道のり
● まとめ
Slide 3
Slide 3 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
自己紹介
3
Slide 4
Slide 4 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
自己紹介
● 角井 暖 / Dan Kadoi
● @cass7ius、 Cassius7
● ERP パッケージベンダーで DevOps を経験し、
2019 年 8 月よりアンドパッドの SREに参画
● 急速に成長するバーティカル SaaS 、
拡大する開発組織ならではの課題を、
Platform・SRE領域の技術で解決する
● SRE チームのリード
● 趣味はゲームと旅行
4
Slide 5
Slide 5 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ANDPADについて
5
Slide 6
Slide 6 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
幸せを築く人を、幸せに。
住まいをつくる。ビルや施設をつくる。街をつくる。
生活を豊かにする建築・建設業は、幸せづくりと例えられます。
私たちは、その幸せづくりをする人たちをテクノロジーの力で
後押ししていきたい。心からそう考えてます。
我々はこれからもお客様の声をサービスに反映して、
建設業界及び建設業従事者様の業務効率化、
DX化を支援してまいります。
万人
ユーザー数
46.1万人
利用社数
18.1万社
※『建設業マネジメントクラウドサービス市場の動向とベンダシェア（ミックITリポート
2023年10月号）』（デロイト トーマツ ミック経済研究所調べ）
4 No.1のインダストリーSaaS
6
Slide 7
Slide 7 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ペインポイント
3
市場規模
社会課題
・人材不足
・低生産性
現場課題
・長時間残業
・低粗利率
建設業界 日本全体
市場規模 50兆円
（日本で2番目）
500兆円
事業者数 50万業者
（3年連続増加）
386万業者
従業者数 500万人 6800万人
7
Pain Point／市場規模
Slide 8
Slide 8 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
経営（社内）
・現場管理
・営業
経営と現場をつなぐクラウドサービス
現場の効率化から経営改善まで一元管理
案件概要
クラウドを活用し、建築業の悩みを全て解決
・経営
・事務
現 場
・協力業者
・職人
工程表 資料 写真 報告確認
チャット（社内外連絡） 経営管理 OB管理 見積作成
受発注 予算管理 入出金管理 検査 施主
図面 法令対応 その他
施工管理から始まる経営改善ツール
8
Slide 9
Slide 9 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ANDPADのSREチーム
9
Slide 10
Slide 10 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
猛烈に成長するスタートアップ
● ビジネスも組織も急速に拡大
● 現場に責任と裁量を与えて、リスクや不確実性と戦う
● カスタマーセントリックにマルチプロダクト開発
開発組織が全力疾走するのに安全で丈夫な道が必要
ANDPADのSREは、その道をつくるチーム
10
Slide 11
Slide 11 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ANDPADのSREチームは担当業務が広い
● ANDPAD、マイクロサービス、コーポレートサイト等の基盤開発
● AWSのマルチアカウントガバナンス整備
● オブザーバビリティの実現、テレメトリの追加収集
● データベースやEKSなどの更新、システムメンテナンスの切り盛り
● 統制維持のための運用、開発で利用するSaaSやアカウントの管理
● インフラの統廃合やサービスクロージング
● 他のチームメンバーと連携して、SPOFや技術的負債へに対処する
11
Slide 12
Slide 12 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
バックログでタスクの優先度や緊急度を整理
12
1. 成果や割り込みを共有
して、業務改善の余地を
振り返る
2. 優先度や緊急度の可視
化→定期的に状態を更新
して認識合わせをする
2は吉澤さんが整理して始
めてくれた取り組みで、
Miroとスプレッドシート
で管理してます！
Slide 13
Slide 13 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ここからコンテナ化の話
13
Slide 14
Slide 14 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
持ち帰っていただけるもの
コンテナ化プロジェクトとその後の変化について話します
● コンテナ化を検討している
● まさに今コンテナ化に苦労している
そんな方をターゲットに弊社事例の紹介をします
技術的な詳細は時間の関係で省略します！
後で紹介する多数のブログ記事をご覧ください🙏
14
Slide 15
Slide 15 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
なぜコンテナ化したのか
15
Slide 16
Slide 16 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
新規サービスはすでにコンテナで稼働させていた
16
マイクロサービス基盤 ANDPAD本体
新規サービスはモダンな
実行基盤でサービス・リ
ポジトリが分割されて立
ち上がる
一方ANDPAD本体は、施
工管理・チャット・ERP
などの基本機能を中心と
したモノリシックサービ
スで、数年かけてリポジ
トリが大きく育っている
メッシュ化された
Ruby on Rails + Sidekiq
Slide 17
Slide 17 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
このモノリシックサービスが、レガシーなインフラでビジネスの拡大を支
えてきた
猛烈に成長するSaaSのインフラを猛烈にカイゼンする技術
歴史に経緯を払う
17
CTOが手動デプロイしてた時代から、デリバリーの仕組みや運用を整
えてきた間に解決された問題や溜まった知見は、貴重な資産
これらなくして「コンテナ化」は成し得てない
Slide 18
Slide 18 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● アプリケーションを実行するVMのOSやパッケージの更新が上手く回っ
てなかった
○ Amazon LinuxのEOLへの対応が必要になった
● リリースが大変な作業で、頻度を上げづらかった
○ 簡素化/高速化が必要になった
● いろんな仕事を詰め込んだバッチサーバがSPOF
SidekiqScheduler/AssetsSync/RailsRunnerやスクリプトのCron実行/DB
migrate/開発者が本番作業を実施する環境
しかしいろいろ辛かった...!!
18
Slide 19
Slide 19 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
前段で取り組んでいたNFS(EC2)の廃止が完
了して、いよいよコンテナ化しやすい状況に
なり、推進の機運が高まる
19
Slide 20
Slide 20 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
20
コンテナ化プロジェクト始動前のインフラ（~2020/09
当時のリリースは大変な作業だった
● スプシを見ながらAWSマネコン操作
● イメージのビルドが長い
● AmazonLinuxの素のAMIから作って
なかったので暗黙知が多い
● フロントサーバのみBlueGreen
● サーバの起動が遅い
● バッチサーバはインプレースアップ
グレード
● ライブラリや言語更新には匠な職人
技が必要なことも
Slide 21
Slide 21 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
コンテナ化する事で、
● サーバのメンテナンス性・変更容易性を上げる
● リリース作業を簡単にして、頻度を上げる
● SPOFを無くす
21
21
足場を強化して、ビジネスの課題・本質的な課題に
開発組織が専念できるようにする
Slide 22
Slide 22 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
コンテナ化の泥臭い道のり
22
Slide 23
Slide 23 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● ローカル環境や、一時的に利用する検証環境の用途でdocker-compose
で小さく起動するナレッジは元々あった
○ それらをサンプルにSETチームを筆頭に検証環境構築
● Sidekiqを安全に終了できない問題が、致命的だった
○ 多くのジョブは5分あれば十分だが、3時間の強者も
○ ECS on Fargateの当時の最大待ち時間は120sec
○ 大量にあるジョブをこの制約に対応させる工数は甚大
ECS on Fargateでコンテナ化を検証（~2020/12
23
Slide 24
Slide 24 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● コンテナ化の要件
○ デリバリー速度を落とさない
○ リリース作業を大きく変えない（既存運用の維持）
○ 現行水準以上の可用性と監視レベル
○ Sidekiqを安全に終了する
● 議論と検証を繰り返して、以下の方向性を決断
○ EKSでコンテナ化する
○ プログラムの改修が多く必要であったバッチサーバのコンテナ化
は、後回しにする（フェーズを2つに分割
議論と検証を繰り返して、方向性を決定 (~2021/03)
24
Slide 25
Slide 25 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
SRE、プロダクト開発エンジニア、などのメンバーと、テックリードが有志
で集まって、調査・議論・実装などをやり始めた
人の出入りがありつつ、この時点では専任担当者なし
25
25
コンテナ化プロジェクトの体制（2021/04~
Slide 26
Slide 26 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
コンテナ化本番リリース
Phase1まで
26
Slide 27
Slide 27 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
既存のナレッジは積極的に流用し、ANDPAD本体のコンテナ化と
そのデリバリー構成を設計
● マニフェストの構成管理 → Helm Chart
● 秘匿情報の管理→ Helm Secrets Plugin + Sops(KMS)
● PumaやHPAの設定を決めるための負荷試験 → Locust
● 古すぎるパッケージがある → Dockerfileで頑張って再現
● 分析用のログをS3に永続化する仕組み → fluent-bit
● 手前のNginxを廃止可能か検討 → Sidecar構成で維持
一部の開発環境をコンテナ化して全体設計（~2021/11
27
Slide 28
Slide 28 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
28
コンテナ化Phase1時点のインフラ構成（2021/12
初回の本番リリースはオンライン中
に手動でカナリアリリースした
TargetGroupBindingsでコンテナ化
ターゲットを構成して、既存のALB
のEC2ターゲットへのルーティング
に少しずつ加重を追加した
Slide 29
Slide 29 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
29
コンテナ化Phase1時点のインフラ構成（2021/12
この時点ではまだバックサーバが
オートスケールしておらず
● EC2時代に使われていたSidekiqメ
トリクスの収集方法では、収集頻度
が少な過ぎて、スパイク的なジョブ
の変化に対してコンテナの伸縮が遅
すぎる問題があった
● この時点では、バックサーバは想定
される最大負荷のスケールで固定し
ていた
● EC2時代と同様に、この時点ではフ
ロントサーバのみBlueGreenDeploy
Slide 30
Slide 30 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● 要件とモチベーションになってた課題はひとまずクリア
● ANDPAD本体のパフォーマンスがやや向上
大きな事故なく初回リリース🎉（2021/12
30
Slide 31
Slide 31 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
コンテナ化本番リリース
Phase2まで
31
Slide 32
Slide 32 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ANDPADの開発ライフサイクルの改善
1. バックサーバもオートスケーリングさせる
2. バッチサーバから仕事を分解して、廃止する
3. バックサーバもBlue/Greenデプロイする
4. リリース作業の負担を下げる/フローを改善する
5. Pumaのパフォーマンス改善
Phase1の初期リリース時点での残課題（2022/01
32
Slide 33
Slide 33 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
バックサーバもオートスケーリングさせる
33
Slide 34
Slide 34 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
EC2時代に使われていたSidekiqメトリクスの収集は、Lambda関数で
Sidekiqメトリクスを収集してDatadogに送る方法だった
スケーリング指標は”リソース利用率”ではなく”仕事率”にしたい
● コンテナを水平スケールさせるにあたり、収集されている情報が古い
● HPAだと特定の指標に対し1つしか閾値が持てない
バックサーバもオートスケーリングさせる（~2022/04
34
この状況では、ジョブのスパイクにスケールを対応させるのが難しく
繰り返し不安定かつ効率の悪いスケーリングを行ってしまう
Slide 35
Slide 35 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● WPA = Datadog製のHPA拡張のカスタムコントローラ を導入
● sidekiq-prometheus-exporter gemを導入して、EKS内の
DatadogAgentのprometheusScrapeでメトリク収集
Sidekiqのオートスケールをイイ感じに（~2022/04
35
Sidekiqのメトリクスを高頻度に収集できるようにして、仕事率を計算
バースト制限、スケーリング速度などを指定して、丁度よくスケーリング
できるようにチューニングした
Slide 36
Slide 36 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
バッチサーバから仕事を分解して、廃止する
36
Slide 37
Slide 37 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
バッチサーバは大きく分けて、以下5つの役割を持っていた
● リリース作業で、DBマイグレートを実行する場所
● 開発者がログインしてデータパッチやその他本番作業を実施する場所
● 定期実行用のSidekiqジョブのエンキュー（Sidekiq scheduler）
● cronで実行されていたRailsRunnerの処理
● cronで実行されていたその他の処理
バッチサーバから仕事を分解する
37
Slide 38
Slide 38 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
以下の移行を、ダウンタイム無しで少しずつ推進した
● DBマイグレートとデータパッチについては、CodeBuildから実行でき
るように個別に再実装した
● その他の本番作業は、ログイン環境を別途用意した
● 定期実行用のSidekiqジョブのエンキュー専用サーバをEKS内に冗長構
成して、バッチサーバでは動作しないようにした
● cronで実行されていたRailsRunnerはSidekiqのジョブとして動く様に
移行した
バッチサーバから仕事を分解する（~2022/12
38
Slide 39
Slide 39 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
技術的な詳細はテックブログをご覧ください
施工管理サービスの定期実行ジョブ処理基盤をEC2からコンテナへ移行しました
データパッチ環境と有事の際のログイン環境をサーバレス化・コンテナ化した取
り組み
バッチサーバから仕事を分解する（~2022/12
39
Slide 40
Slide 40 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
バックサーバもBlue/Greenデプロイする
40
Slide 41
Slide 41 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● 元々1つのみで運用していたRedis namespaceを3系統に分割
（Blue/Green/ScheduledJob）
● 新バージョンのフロントサーバから積まれるキューを処理する新バー
ジョンのバックサーバを用意できるようになった
● 定期実行処理は引き続きローリングアップデートをするために、独立
したRedis namespaceを用意
● Sidekiqを7系以降はRedis namespaceがサポートされないので、この3
系統分割はRedis databaseで表現する
バックサーバもBlue/Greenデプロイする（~2022/12
41
Slide 42
Slide 42 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
技術的な詳細はテックブログをご覧ください
2部構成です
施工管理サービスの非同期処理基盤をBlue/Greenデプロイ化しました[前編]
施工管理サービスの非同期処理基盤をBlue/Greenデプロイ化しました[後編]
バックサーバもBlue/Greenデプロイする（~2022/12
42
Slide 43
Slide 43 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● cronで実行されていたその他の処理の移行
● その他とは、Goバイナリの処理や超長時間かかるKPIデータ作成処理
バッチサーバから最後の仕事を剥がす（~2023/03
43
これらはECS scheduled Taskに移行した（~2023/03
こちらを対応後、バッチサーバの廃止を実行して、
コンテナ化プロジェクトは解散
Slide 44
Slide 44 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
最終的な構成
44
Slide 45
Slide 45 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
45
コンテナ化Phase2時点のインフラ構成（2023/04
バッチサーバ廃止時点の構成
● バッチサーバから仕事を分解するプ
ロセス、EKSのリソース構成検討、
古い処理のコンテキストキャッチ
アップ、移行戦略の検討、スクリプ
トやプログラムの修正など作業量が
膨大で、多段リリース
● コンテナ化プロジェクト始動から作
られたリソースの大部分はIaCさ
れ、再現可能になった
Slide 46
Slide 46 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
まとめ
46
Slide 47
Slide 47 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● イメージビルドはキャッシュや成果物のコピーやパッケージの最新化
などで時短し、開発環境のデプロイは速く簡単になり、大好評
● リリース作業とデータパッチ作業は、スクリプトの改修とフロー整理
で大幅に簡単化し、人的ミス削減や時短に成功
● サーバーの再現性・可搬性が向上したりデリバリーの仕組みシンプル
になったことで、開発者が改修可能になった
開発体験やリリース作業が改善された🎉
47
Slide 48
Slide 48 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● 勢いよく育ったRuby on Rails + Sidekiq構成のモノリシックサービス
をコンテナ化するのは大変
○ バッチサーバは魔窟で、ローカルファイルに頼った排他制御が
あったり、オーナーが不明で手を入れるにはオブザーバビリティ
が乏しい処理や、安全に出来ると思った移行が障害を起こすな
ど、多くの苦労を伴った
● “どこでも動くようにつくる”設計が非常に重要
コンテナ化プロジェクト全体を通して
48
Slide 49
Slide 49 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
● 今回は割愛したが、パフォーマンスチューニングは難しい
○ 正確にやるにはオブザーバビリティの実現と、staging環境もしく
は高度なロードテストの仕組みが必要
● Kubernetes環境では、単に監視をしているだけでは絶え間なく発生す
る動的な出来事に関連性を見出すのが難しい
○ テレメトリの追加や紐付けなどのセットアップをする
○ 事実や状況証拠を束ねて、事象の理解に努める
コンテナ化プロジェクト全体を通して
49
Slide 50
Slide 50 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
We are hiring!
50
https://engineer.andpad.co.jp/
技術スタックや募集ポジションを
掲載してます！
Slide 51
Slide 51 text
Copyright © 2023 ANDPAD Inc. All Rights Reserved.
ご静聴ありがとうございました！
51