EC2からECSへ念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築

by すみや

Slide 1

Slide 1 text

EC2からECSへ念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築 2024年12月22日江口純矢 PHP Conference Japan 2024

Slide 2

Slide 2 text

2 経歴 2021年、コドモンにエンジニアとして新卒で入社し請求関連のプロダクトを作成するチームに所属。その後、プッシュ通知の基盤を新しく作り直すプロジェクトを経て、SREにジョイン。最近ハマっていること早起きしてスーパー銭湯に行った後、ハッピーアワーで昼飲み。自己紹介江口純矢えぐちすみや X:@egusumi1219

Slide 3

Slide 3 text

3 Mission

Slide 4

Slide 4 text

4 すべての先生に子どもと向き合う時間と心のゆとりをこんなプロダクトを開発していますメインプロダクトは、保育・教育施設向けWebアプリケーション。保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版アプリケーション、外部サービスと連携するAPIなども開発しています。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 レガシーシステムの運用に頭を悩ませている方手を上げてください

Slide 7

Slide 7 text

7 コドモンでは長年このような状態でした

Slide 8

Slide 8 text

8 少し長めの導入ですが、お付き合いください

Slide 9

Slide 9 text

9 1. 環境ごとに差異が生じやすくなっている 2. 本番リリースの時間が長く、リリース頻度を増やすのが困難

Slide 10

Slide 10 text

10 1. 環境ごとに差異が生じやすくなっている 2. 本番リリースの時間が長く、リリース頻度を増やすのが困難

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

15 1. 環境ごとに差異が生じやすくなっている 2. 本番リリースの時間が長く、リリース頻度を増やすのが困難

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 CONFIDENTIAL - © 2022 CoDMON Inc. 23 二つの課題を整理コドモンにおけるレガシーシステムの課題ローカル環境と本番環境が異なる方法で構成管理される ● 差分が生まれやすい ● 管理責務が別れ、SREと機能開発チームの双方に作業のコストが発生複数チームが関係するサービスがEC2で動いている ● EC2のデプロイ時間が長く、リリース頻度を増やす障壁になっているコンテナ化すれば解決する！

Slide 24

Slide 24 text

24 とはいえ...

Slide 25

Slide 25 text

25 他の業務もある中この状況に手をつけられず

Slide 26

Slide 26 text

26 数年の時が経過しました...

Slide 27

Slide 27 text

27 時が経ち

Slide 28

Slide 28 text

28 そこで一人の若手エンジニアが

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 ところが...

Slide 31

Slide 31 text

31 実際作業に取り掛かると

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

35 今日伝えたいこと

Slide 36

Slide 36 text

36 巨大レガシーシステムのコンテナ移行は総力戦

Slide 37

Slide 37 text

37 一人ではなくみんなの力で達成するもの

Slide 38

Slide 38 text

38 3 2 1 今日話すことコンテナイメージの作成には横断的な協力が必要安全に移行するための工夫移行作業と多岐にわたる移行対象の監視

Slide 39

Slide 39 text

39 CONFIDENTIAL - © 2022 CoDMON Inc. 39 コンテナ化の目的 1.コンテナイメージの作成には横断的な協力が必要ローカル環境と本番環境が異なる方法で構成管理される ● 差分が生まれやすい ● 管理責務が別れ、SREと機能開発チームの双方に作業のコストが発生複数チームが関係するサービスがEC2で動いている ● EC2のデプロイ時間が長く、リリース頻度を増やす障壁になっている

Slide 40

Slide 40 text

40 CONFIDENTIAL - © 2022 CoDMON Inc. 40 コンテナ化の目的 1.コンテナイメージの作成には横断的な協力が必要ローカル環境と本番環境が異なる方法で構成管理される ● 差分が生まれやすい ● 管理責務が別れ、SREと機能開発チームの双方に作業のコストが発生複数チームが関係するサービスがEC2で動いている ● EC2のデプロイ時間が長く、リリース頻度を増やす障壁になっている →環境ごとの差異を減らす →本番リリース時間の短縮

Slide 41

Slide 41 text

Slide 42

Slide 42 text

42 まずはインフラの全体構成図から

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

56 CONFIDENTIAL - © 2022 CoDMON Inc. 56 ベースイメージの選定 1.コンテナイメージの作成には横断的な協力が必要 debian:bookworm-slim ubuntu:noble amazonlinux:2023 イメージ全体の容量 1.8~2GBぐらい 1.8~2GBぐらい 2GB超セキュリティアップデート頻度多い多い少ないコミュニティ規模開発コミュニティ大開発コミュニティ大 AWSに閉じているため比較的小さい EOL 2026/6/10 2029/04/25 2025/6/30 その他安定性重視傾向 DockerHubの公式イメージの多くは Debianベーススピード重視傾向 DebianベースのOS ・AWSと相性良し安定性を重視して Debianを採用採用

Slide 57

Slide 57 text

57 ここからが大変な作業

Slide 58

Slide 58 text

Slide 59

Slide 59 text

59 CONFIDENTIAL - © 2022 CoDMON Inc. 59 メインのEC2は複数チームで開発 1.コンテナイメージの作成には横断的な協力が必要 Apache Source Code team B team C team A team D SRE team ソースコードを複数チームで開発プロダクトの成長によりソースコードが複雑化なぜ、誰が、いつ、入れたかわからないパッケージが複数存在

Slide 60

Slide 60 text

60 CONFIDENTIAL - © 2022 CoDMON Inc. 60 メインのEC2は複数チームで開発 1.コンテナイメージの作成には横断的な協力が必要 Apache Source Code team B team C team A team D SRE team ソースコードを複数チームで開発プロダクトの成長によりソースコードが複雑化なぜ、誰が、いつ、入れたかわからないパッケージが複数存在複数チームからの協力が不可欠

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

65 CONFIDENTIAL - © 2022 CoDMON Inc. 65 AmazonLinuxで動いていたコンテナをDebianで再構築 1.コンテナイメージの作成には横断的な協力が必要規模が大きく依存ライブラリの数が膨大二つのOSでphpinfo()を実行しパッケージの差分を地道に埋める Ansibleに書かれていたコマンドを一つ一つDockerﬁleに移すどこで使われているかそもそもわからない

Slide 66

Slide 66 text

66 CONFIDENTIAL - © 2022 CoDMON Inc. 66 AmazonLinuxで動いていたコンテナをDebianで再構築 1.コンテナイメージの作成には横断的な協力が必要規模が大きく依存ライブラリの数が膨大二つのOSでphpinfo()を実行しパッケージの差分を地道に埋める Ansibleに書かれていたコマンドを一つ一つDockerﬁleに移すどこで使われているかそもそもわからないアプリケーションエンジニアやQAに都度相談して動作確認

Slide 67

Slide 67 text

67 CONFIDENTIAL - © 2022 CoDMON Inc. 67 AmazonLinuxで動いていたコンテナをDebianで再構築 1.コンテナイメージの作成には横断的な協力が必要二つのOSでphpinfo()を実行しパッケージの差分を地道に埋める Ansibleに書かれていたコマンドを一つ一つDockerﬁleに移すアプリケーションエンジニアやQAに都度相談して動作確認地道な作業の積み重ねでコンテナイメージがなんとか形に規模が大きく依存ライブラリの数が膨大どこで使われているかそもそもわからない

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

71 CONFIDENTIAL - © 2022 CoDMON Inc. 71 1.コンテナイメージの作成には横断的な協力が必要 ● ソースコードの環境依存をイメージから追い出す ○ ビルド時に環境依存値を埋め込まない形に修正 ● 追い出した環境依存値をコンテナ起動時に取得する ○ 環境変数値はコンテナ(ECSタスク)起動時にSecrets Managerから取得可能各環境でイメージを共通化する時にやること

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

90 一区切りついたので他のポイントも紹介させてください

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

95 CONFIDENTIAL - © 2022 CoDMON Inc. 95 Apacheの処理方式を見直し Apacheの処理方式 prefork worker event メモリ httpd プロセス httpd プロセス・・・・・スレッド1 スレッド1 CPU コアコアコアコア httpリクエスト命令 httpリクエストメモリ httpd プロセス・・・・・スレッド1 CPU コアコアコアコア httpリクエスト命令 httpリクエストスレッド2 スレッド3 httpリクエストメモリ httpd プロセス・・・・・スレッド1 CPU コアコアコアコア httpリクエスト命令 httpリクエストスレッド2 スレッド3 httpリクエスト workerとほぼ同じプロセス数不足をトリガーに・新規プロセスを起動・既存プロセスを停止処理効率 Apacheの処理を効率化するためPHPを変更モジュール版PHPでは使用不可モジュール版PHPでは使用不可

Slide 96

Slide 96 text

96 CONFIDENTIAL - © 2022 CoDMON Inc. 96 処理効率が最も良いevent方式では、502エラーとなるため、workerを採用 Apacheの処理を効率化するためPHPを変更約0.5%の割合で 502エラー Apache MPM イベントモジュールは、ロードバランサーからの接続を早期に切断する可能性があります。接続が早期に切断されると、Application Load Balancer では HTTP 502 エラーが生成されます。抑制するためには、代わりに MPM ワーカーモジュールを使用するのがベストプラクティスです。 “ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。” https://repost.aws/ja/knowledge-center/apache-backend-elb

Slide 97

Slide 97 text

97 CONFIDENTIAL - © 2022 CoDMON Inc. 97 負荷試験の結果、Apacheの処理方式を変更 Apacheの処理方式 prefork worker event メモリ httpd プロセス httpd プロセス・・・・・スレッド1 スレッド1 CPU コアコアコアコア httpリクエスト命令 httpリクエストメモリ httpd プロセス・・・・・スレッド1 CPU コアコアコアコア httpリクエスト命令 httpリクエストスレッド2 スレッド3 httpリクエストメモリ httpd プロセス・・・・・スレッド1 CPU コアコアコアコア httpリクエスト命令 httpリクエストスレッド2 スレッド3 httpリクエスト workerとほぼ同じプロセス数不足をトリガーに・新規プロセスを起動・既存プロセスを停止採用 Apacheの処理を効率化するためPHPを変更モジュール版PHPでは使用不可モジュール版PHPでは使用不可処理効率約0.5%の割合で502エラー

Slide 98

Slide 98 text

Slide 99

Slide 99 text

99 2 1 3 今日話すことコンテナイメージの作成には横断的な協力が必要安全に移行するための工夫移行作業と多岐にわたる移行対象の監視

Slide 100

Slide 100 text

100 ここからが本番

Slide 101

Slide 101 text

101 ここまで総力を上げて作ったコンテナを安全にリリースしたい

Slide 102

Slide 102 text

102 とはいえ、どこで問題が起きるかわからない

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

Slide 106

Slide 106 text

Slide 107

Slide 107 text

Slide 108

Slide 108 text

Slide 109

Slide 109 text

Slide 110

Slide 110 text

110 CONFIDENTIAL - © 2022 CoDMON Inc. 110 なぜ非互換なPRになったのか？ 2.安全に移行するための工夫移行前のEC2 移行後のECS 変更差分大 PHPの設定を .htaccessに記述 PHPの設定を user.iniに記述 EC2とECSの両方で動く書き方に変更し、PRをマージモジュール版PHP FastCGI版PHP prefork worker preforkの時のみ設定を読み込む書き方に変更

Slide 111

Slide 111 text

111 CONFIDENTIAL - © 2022 CoDMON Inc. 111 なぜ非互換なPRになったのか？ 2.安全に移行するための工夫移行前のEC2 移行後のECS 変更差分大 PHPの設定を .htaccessに記述 PHPの設定を user.iniに記述 EC2とECSの両方で動く書き方に変更し、PRをマージモジュール版PHP FastCGI版PHP 巨大PRの解体をきっかけに段階的な移行を意識するように

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

115 CONFIDENTIAL - © 2022 CoDMON Inc. 115 移行前のEC2に影響を与えずにECSへリリースするための工夫 2.安全に移行するための工夫移行前EC2 移行後ECS 両方を同じ状態に test slack slack call 既存ワークフローに追加できない合計20 1 つのワークフローファイルから最大 20 個の一意の再利用可能なワークフローを呼び出すことができます。 “ワークフローの再利用 > 制限事項” https://docs.github.com/ja/actions/sharing-automations/reusing-workflows 既存ワークフロー

Slide 116

Slide 116 text

116 CONFIDENTIAL - © 2022 CoDMON Inc. 116 移行前のEC2に影響を与えずにECSへリリースするための工夫 2.安全に移行するための工夫移行前EC2 移行後ECS 既存ワークフロー test slack slack call ECS用ワークフロー test slack call work ﬂow run経由で実行 ECSへのデプロイ結果が既存ワークフローに影響しない

Slide 117

Slide 117 text

Slide 118

Slide 118 text

Slide 119

Slide 119 text

Slide 120

Slide 120 text

Slide 121

Slide 121 text

121 CONFIDENTIAL - © 2022 CoDMON Inc. 121 ルール1 target_group1に転送移行対象のEC2 ECS移行前に本番環境で動作確認するための工夫 2.安全に移行するための工夫移行対象のECS target_group1 ユーザー開発者 443/ https xxxx/ https ルール2 target_group2に転送 target_group2 開発者以外はアクセスできない OIDCによる認証ユーザーに公開する前に動作確認可能

Slide 122

Slide 122 text

Slide 123

Slide 123 text

Slide 124

Slide 124 text

Slide 125

Slide 125 text

Slide 126

Slide 126 text

126 CONFIDENTIAL - © 2022 CoDMON Inc. 126 移行対象のEC2 当初考えていた移行の方法 2.安全に移行するための工夫マイクロサービス1 マイクロサービス2 移行対象のECS Route53の加重ルーティングにより段階移行各マイクロサービスECSに新しいALB用ターゲットグループが必要 ECS サービスに登録できるターゲットグループの上限は5つ各マイクロサービスチームでターゲットグループを作る手間が発生既にターゲットグループが 3つ以上登録されているマイクロサービスが複数存在

Slide 127

Slide 127 text

127 CONFIDENTIAL - © 2022 CoDMON Inc. 127 移行対象のEC2 当初考えていた移行の方法 2.安全に移行するための工夫マイクロサービス1 マイクロサービス2 移行対象のECS Route53の加重ルーティングにより段階移行各マイクロサービスECSに新しいALB用ターゲットグループが必要 ECS サービスに登録できるターゲットグループの上限は5つ各マイクロサービスチームでターゲットグループを作る手間が発生既にターゲットグループが 3つ以上登録されているマイクロサービスが複数存在別の方法を検討

Slide 128

Slide 128 text

128 CONFIDENTIAL - © 2022 CoDMON Inc. 128 移行対象のEC2 リスナールールに着目し再検討 2.安全に移行するための工夫マイクロサービス1 マイクロサービス2 移行対象のECS ルール1 target_group1:100% ルール2 target_group2:100% ルール3 target_group_3:100% target_group2 target_group3 target_group1

Slide 129

Slide 129 text

129 CONFIDENTIAL - © 2022 CoDMON Inc. 129 移行対象のEC2 リスナールールに着目し再検討 2.安全に移行するための工夫マイクロサービス1 マイクロサービス2 移行対象のECS ルール1 target_group1:100% ルール2 target_group2:100% ルール3 target_group_3:100% target_group2 target_group3 target_group1

Slide 130

Slide 130 text

130 CONFIDENTIAL - © 2022 CoDMON Inc. 130 移行対象のEC2 リスナールールに着目し再検討 2.安全に移行するための工夫マイクロサービス1 マイクロサービス2 移行対象のECS ルール1 target_group1:100% target_group4:0% ルール2 target_group2:100% ルール3 target_group_3:100% target_group2 target_group3 target_group1 target_group4 リスナールールによってターゲットグループで加重設定

Slide 131

Slide 131 text

131 CONFIDENTIAL - © 2022 CoDMON Inc. 131 移行対象のEC2 リスナールールに着目し再検討 2.安全に移行するための工夫マイクロサービス1 マイクロサービス2 移行対象のECS ルール1 target_group1:100% target_group4:0% ルール2 target_group2:100% ルール3 target_group_3:100% target_group2 target_group3 target_group1 target_group4 リスナールールによってターゲットグループで加重設定各マイクロサービス用のターゲットグループの新規作成が不要

Slide 132

Slide 132 text

132 CONFIDENTIAL - © 2022 CoDMON Inc. 132 まとめ 2.安全に移行するための工夫 1. PRを大きくせず、ビッグバンリリースしないための工夫 →EC2とECSの両方で動くようにソースコードを修正 2. 移行前のEC2に影響を与えずに ECSへリリースするための工夫 →EC2へのデプロイが完了した後 ECSがデプロイされる仕組みを作成 3. ECS移行前に本番環境で動作確認するための工夫 →ALBに認証を設けて、開発者だけが ECSで動作確認できる仕組みを作成 4. 段階的に移行するための工夫 →ALBの加重設定を使用し、徐々にトラフィックを流せる仕組みを作成

Slide 133

Slide 133 text

133 ついでに

Slide 134

Slide 134 text

134 デプロイ方式について

Slide 135

Slide 135 text

Slide 136

Slide 136 text

Slide 137

Slide 137 text

Slide 138

Slide 138 text

Slide 139

Slide 139 text

139 CONFIDENTIAL - © 2022 CoDMON Inc. 139 ローリングアップデートとBlue/Greenの比較 2.安全に移行するための工夫ローリングアップデート前ローリングアップデート後ローリングアップデートフロントとバックエンドが同一のECSにローリングアップデート中は新旧のインスタンスが混在フロントのみS3などに分離 Blue/Greenデプロイに変更するデプロイ期間中フロントとバックエンドがで不一致が生じる

Slide 140

Slide 140 text

140 CONFIDENTIAL - © 2022 CoDMON Inc. 140 ローリングアップデートとBlue/Greenの比較 2.安全に移行するための工夫ローリングアップデート前ローリングアップデート後ローリングアップデートフロントとバックエンドが同一のECSにローリングアップデート中は新旧のインスタンスが混在フロントのみS3などに分離 Blue/Greenデプロイに変更するデプロイ期間中フロントとバックエンドがで不一致が生じる

Slide 141

Slide 141 text

141 CONFIDENTIAL - © 2022 CoDMON Inc. 141 ローリングアップデートとBlue/Greenの比較 2.安全に移行するための工夫ローリングアップデート前ローリングアップデート後ローリングアップデートフロントとバックエンドが同一のECSにローリングアップデート中は新旧のインスタンスが混在フロントのみS3などに分離 Blue/Greenデプロイに変更する採用デプロイ期間中フロントとバックエンドがで不一致が生じる

Slide 142

Slide 142 text

Slide 143

Slide 143 text

Slide 144

Slide 144 text

Slide 145

Slide 145 text

Slide 146

Slide 146 text

Slide 147

Slide 147 text

Slide 148

Slide 148 text

148 CONFIDENTIAL - © 2022 CoDMON Inc. 148 ローリングアップデートとBlue/Greenの比較 2.安全に移行するための工夫 Green Blue/Greenデプロイ ALBのリスナールールによる加重設定と Blue/Greenデプロイは併用できない Blue/Greenデプロイを使用する場合対象のECSサービスに登録できるターゲットグループは 1つまでデプロイ方式をローリングアップデートから Blue/Greenに切り替える際 ECS Serviceを作り直す必要がある

Slide 149

Slide 149 text

149 制約の多いBlue/Greenデプロイは基本的には採用しない方針に

Slide 150

Slide 150 text

150 フロントとバックエンドが分離されてない今回のサービスではBlue/Greenデプロイを採用

Slide 151

Slide 151 text

Slide 152

Slide 152 text

Slide 153

Slide 153 text

Slide 154

Slide 154 text

Slide 155

Slide 155 text

Slide 156

Slide 156 text

Slide 157

Slide 157 text

Slide 158

Slide 158 text

Slide 159

Slide 159 text

Slide 160

Slide 160 text

160 3 2 1 今日話すことコンテナイメージの作成には横断的な協力が必要安全に移行するための工夫移行作業と多岐にわたる移行対象の監視

Slide 161

Slide 161 text

161 いよいよ最後

Slide 162

Slide 162 text

Slide 163

Slide 163 text

163 実はもう少し複雑

Slide 164

Slide 164 text

Slide 165

Slide 165 text

Slide 166

Slide 166 text

Slide 167

Slide 167 text

Slide 168

Slide 168 text

168 CONFIDENTIAL - © 2022 CoDMON Inc. 168 本当の移行作業の流れ 4.移行作業と多岐にわたる移行対象の監視移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ影響の範囲を抑えながら順次実行

Slide 169

Slide 169 text

169 CONFIDENTIAL - © 2022 CoDMON Inc. 169 本当の移行作業の流れ 4.移行作業と多岐にわたる移行対象の監視移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ影響の範囲を抑えながら順次実行移行完了後 Blue/Greenデプロイに切り替え

Slide 170

Slide 170 text

170 CONFIDENTIAL - © 2022 CoDMON Inc. 170 本当の移行作業の流れ 4.移行作業と多岐にわたる移行対象の監視移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ EC2のトラフィックを徐々にECSへ移行完了後 Blue/Greenデプロイに切り替え EC2のトラフィックを徐々にECSへ影響の範囲を抑えながら順次実行移行完了後 Blue/Greenデプロイに切り替えフロントとバックエンドの不一致が起きないサービスではローリングアップデートを採用

Slide 171

Slide 171 text

Slide 172

Slide 172 text

Slide 173

Slide 173 text

Slide 174

Slide 174 text

Slide 175

Slide 175 text

Slide 176

Slide 176 text

Slide 177

Slide 177 text

177 ですが

Slide 178

Slide 178 text

178 改めて今回の成果

Slide 179

Slide 179 text

Slide 180

Slide 180 text

Slide 181

Slide 181 text

181 最後に

Slide 182

Slide 182 text

182 移行作業を振り返って

Slide 183

Slide 183 text

183 CONFIDENTIAL - © 2022 CoDMON Inc. 183 AmazonLinuxで動いていたコンテナをDebianで再構築二つのOSでphpinfo()を実行しパッケージの差分を地道に埋める Ansibleに書かれていたコマンドを一つ一つDockerﬁleに移すアプリケーションエンジニアやQAに都度相談して動作確認地道な作業の積み重ねでコンテナイメージがなんとか形に規模が大きく依存ライブラリの数が膨大どこで使われているかそもそもわからない

Slide 184

Slide 184 text

Slide 185

Slide 185 text

Slide 186

Slide 186 text

186 多くの人に支えられていることを実感するプロジェクトでした

Slide 187

Slide 187 text

187 皆さんも、大きな挑戦をしたとき周りの支えに救われた経験があるのではないでしょうか？

Slide 188

Slide 188 text

188 今日伝えたいこと

Slide 189

Slide 189 text

189 巨大レガシーシステムのコンテナ移行は総力戦

Slide 190

Slide 190 text

190 一人ではなくみんなの力で達成するもの

Slide 191

Slide 191 text

191 まだまだ多くの協力が必要です

Slide 192

Slide 192 text

192 コドモン採用ページ開発ブログコドモンでは一緒に働きたい仲間を募集しています！