Heroku→AWS移行でのトラブル全部見せます

Heroku→AWS移⾏の トラブル全部⾒せます Grounding our journey - Herokuからの卒業 - Hack@DELTA ツクリンク株式会社 あっきー（@kuronekopunk）

• https://hack-at-delta.connpass.com/event/323377/
• https://x.com/kuronekopunk

⾃⼰紹介 ● あっきー @kuronekopunk ● ツクリンク株式会社 ● 経歴 ○ ○ エンジニアリングマネージャー 2011年 新卒 SESでPHP 2012年 ㈱ハンズシェア創業（現：ツクリンク㈱） ■ ツクリンクの0→1の開発 ■ PHP→Railsのリプレース ■ SEO、グロースハック ■ データアナリスト ■ DevRel ● イベント『EMゆるミートアップ』 ● ポッドキャスト『ぐんぐんfm』 #hack_at_delta

• https://x.com/kuronekopunk
• https://em-yuru-meetup.connpass.com/
• https://podcasters.spotify.com/pod/show/gungunfm

会社‧事業について 「⾼齢化と慢性的な⼈⼿不⾜」により、 建設業そのものが持続困難となる可能性がある。 ⼈⼿不⾜を解消するにはこれまでの当たり前を変える必要がある。 労働環境を改善し、正当な賃⾦が得られるように。 これからの⽇本を⽀える多くの若者が憧れ、 PURPOSE 働きたいとこぞって集まる産業へと業界⾃体を リブランディングしていく。 産業構造を変え、 豊かな未来をつくる つくるひと。つかうひと。 建設業に携わるすべてのひとをテクノロジーで幸せに。 まずは発注者‧受注者の⾮効率な⼈員の配分を効率化するために。 #hack_at_delta

会社‧事業について #hack_at_delta

おしながき 1. Heroku導⼊の背景 2. Heroku卒業の背景 3. 移⾏スケジュール 4. アーキテクチャ 5. 設計、検証での苦労 6. 移⾏でのトラブル 7. 移⾏後の課題 8. さいごに #hack_at_delta

Heroku導⼊の背景

Heroku導⼊の背景（2014年） 『ナウいから』 ノリと勢いでPHP→Railsへのリプレース エンジニア2名 インフラを⾒ている余裕は無い #hack_at_delta

Heroku卒業の背景

組織拡⼤、インフラを⾒るメンバーが増えた Heroku利⽤開始から8年、エンジニアも増え、信頼性向上のためSREチーム組成 #hack_at_delta

細かな設定‧調整をしたい ● 「(メモリ|ストレージ)だけ増やしたい」というケースに対応できなかった ● 全てのスペックが上がり料⾦も上がりやすい #hack_at_delta

slugサイズ上限 ● slugサイズの上限を超えることがある ● 容量削減の作業コストが⼤きくなる ※AWS移⾏後も容量削減や軽量なアプリケーションへの改善は必要 https://devcenter.heroku.com/ja/articles/slug-compiler#slug-size #hack_at_delta

• https://devcenter.heroku.com/ja/articles/slug-compiler#slug-size

耐障害性、冗⻑化対応 ● B/Gデプロイメント対応したい ○ ● デプロイ後アプリが⽴ち上がらない状態でリリースされてしまうインシデントが発⽣ Heroku Schedulerの発⽕が保証されない ○ アドオン Dead Man’s Snitch で監視はしていても再実⾏の⼿間がかかる #hack_at_delta

移⾏スケジュール

全体の移⾏計画 ７ヶ⽉で移⾏完了 4名で実施（ツクリンク社員２名、移⾏ベンダー２名） 2023/3 移⾏計画作成、ベンダー選定 2023/4~7 要件定義、PoC作成、検証 2023/8 テスト実施 2023/9 AWS移⾏実施 #hack_at_delta

今回のAWS移⾏はDELTAさんに協⼒いただきました👏 https://teamdelta.jp/ #hack_at_delta

• https://teamdelta.jp/

当⽇の移⾏計画 夜間８時間のサービス停⽌ 22:00 Heroku メンテナンスモード有効化 22:30 DB, Redisバックアップ取得 24:00 DNS切り替え、DBリストア 24:30 AWSへのデプロイ 25:00 Redisリストア、Elasticsearch index作成 26:00 動作検証 28:00 ECS スケジュールされたタスク（cron）有効化 28:10 メンテナンスモード中に実⾏されなかったcronの実⾏ 29:00 AWSサーバーのメンテナンスモード解除 30:00 最終動作確認、完了 #hack_at_delta

アーキテクチャ

Herokuの利⽤状況 ● エンタープライズ利⽤ ● Dyno（サーバー） ● ○ Webアプリケーション ○ clock（cron） ○ Worker（バックグラウンドJob） アドオン ○ PostgreSQL ○ Redis ○ Elasticsearch ○ Heroku Scheduler（cronと併⽤） #hack_at_delta

AWSアーキテクチャ #hack_at_delta

デプロイフローの変更点

設計、検証での苦労

環境変数 Herokuの環境変数 192個 #hack_at_delta

環境変数を分別 機能設定 FeatureフラグやSlackの通知先チャンネルなどアプリケーションの挙動を変 えるもの 機密性は低い、変更できる必要がある 静的な環境設定 環境構築時に⼀意に定まる情報（RAILS_ENVやTerraform内で⽣成されるリ ソースのアクセサなど） 機密性は低い、変更できる必要がない 動的な環境設定 プロセス数、スレッド数、DBプール数など、環境や周辺のリソースによって 定まるもの 機密性は低い、変更できる必要がある 鍵情報 シークレットや外部サービスの鍵情報など 機密性が⾼い #hack_at_delta

環境変数の管理場所 機能設定 .envファイル デプロイ時にS3に配置、ECSに読み込む 静的な環境設定 tfstate 動的な環境設定 tfstate 鍵情報 Secrets Manager #hack_at_delta

Heroku独⾃の環境変数を使っていた 例：`DYNO` →AWS側で同じ環境変数に詰めた ※この変数名は良くなかったと反省... #hack_at_delta

S3のクロスアカウントアクセス Heroku時に利⽤していたS3は残したまま、新しいAWSアカウントから読み書き をすることにした →検証するとファイルが⾒られなかった 詳細はDELTAテックブログで https://zenn.dev/delta/articles/3fa05d8ecf236d #hack_at_delta

• https://zenn.dev/delta/articles/3fa05d8ecf236d

DBリストアに課題 DBのdump取得‧リストアに ９時間 #hack_at_delta

DBリストアの時間短縮 巨⼤なテーブルのdump取得‧リストアに９時間かかることが発覚 1. 対象テーブルの変更がない古い部分を事前に移⾏しておく 2. AWS移⾏当⽇は移⾏していないデータのみリストア →１時間弱で実施可能に #hack_at_delta

移⾏でのトラブル

「メールが届かないです」

Jobの実⾏遅延 ● 約10万件のJobが詰まる ● 7時間の遅延 #hack_at_delta

Jobの実⾏遅延 テーブルを分割して特殊な⽅法でリストアしたことによりプライマリキーとイン デックスが消失していた… ● プライマリキーがないためINSERTするJobに失敗→Job再実⾏ ● インデックス不在によりスロークエリ発⽣→Jobを専有する →タイムアウトにより再実⾏に積まれる ○ 【対応】 `create index concurrently` を使いDBロックさせずにインデックス作成 #hack_at_delta

「ページが開けないです」

「Retry later」とだけ表⽰される ● Rack::Attack がアクセスをブロックしている時に表⽰されるもの ● Botなどの異常な数のアクセスをスロットリングするために利⽤している ● 誤検知で通常のユーザーまでブロックしているように⾒える… ※イメージ #hack_at_delta

ALBのIPがそのままアプリケーションに渡されていた Rack::Attackが参照するIPがALBのIPになっていた ALBを通すとリクエストヘッダー `X-Forwarded-For` にクライアントIPが⼊る 参考：https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/x-forwarded-headers.html 【対応】 ● ● Rack::Attackの無効化 ログ出⼒に`X-Forwarded-For` を出⼒ 参考：https://morizyun.github.io/ruby/rails-controller-get-ip.html #hack_at_delta

• https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/x-forwarded-headers.html
• https://morizyun.github.io/ruby/rails-controller-get-ip.html

「ログインがすぐ切れる」

Redis容量逼迫 Redis容量が100％ 新しいセッションが登録されるたびに古いセッションが消されている... 【⼀次対応】Redisのスケールアップ #hack_at_delta

Redis容量逼迫 ● Redisデータ移⾏時にTTLが⽋損していた（バックアップ取得のオプションミス） ● Eviction（容量がいっぱいになった場合の削除挙動）の設定 ○ ● volatile-lru：TTLが設定されてる中から、利⽤から最も経過しているキーを削除 expireの無いデータが専有し、新しいデータから削除が始まった #hack_at_delta

Redis容量逼迫 【事後対応】 ● Evictionをallkeys-lru（全てのキーから利⽤から最も経過しているキーを削除） ● 必要以上に⻑いセッション保持期間があったので⾒直し ○ ログイン情報は⻑めに持ち、不必要に⻑く保持していたセッション管理の情報を短く #hack_at_delta

移⾏後の課題

環境変数の変更が重い Herokuは管理画⾯ポチポチで完了（1,2分） 現在はGitHubで.envファイルをコード管理、デプロイを伴う（20分） レビューができる履歴が残るというメリットはあるものの Featureフラグ管理としては使いづらい 【改善検討中】 ● アプリケーションの実装含めたFeatureフラグの運⽤⽅法変更 ● デプロイフローの改善 #hack_at_delta

ReviewApp HerokuではPR作成からボタン1つで検証環境（ReviewApp）が作れた これをAWS環境ではGitHub Actionsで実現する これによりAWS移⾏後もステージング環境デプロイ前（mainへのマージ前）に UI‧動作の確認を可能にした #hack_at_delta

定期実⾏タスク監視 CloudWatch アラームでスケジュールされたタスクの実⾏を監視 対象時間にCloudWatch Logsにログが流れなければアラート発⽕ 現状は検知だけで再実⾏不可能 【改善検討中】 今後はCloudFormationを噛ませて再実⾏可能にしたい #hack_at_delta

さいごに

PR 本⽇話した内容の深堀り、その他雑談でもOK お気軽にどうぞ󰢨 https://forms.gle/h6GuC9RkGMwRhezx9 #hack_at_delta

• https://forms.gle/h6GuC9RkGMwRhezx9

Thanks. 🙌 Hack@DELTA