「社内で手軽にHTTPSを使いたい！」を支える化石システムのAWSへのリプレイス

「社内で手軽にHTTPSを使いたい！」を支える 化石システムのAWSへのリプレイス 2025.06.20 @ Engineering Productivity Meetup #4 in 東京 生産性向上チーム 佐々木勝一 a.k.a. Show 1

生産性向上チーム2年目 Show（@ajfAfg） プログラミング言語と型が好き 2

目次 01 背景 P04 02 リプレイスの概要 P11 03 技術選定まつり P18 04 とある事件 P21 05 おまけ（補足資料） P27 3

背景 4

開発環境でHTTPS 使いたくないですか！？ 5

使いたいですよね！？ 6

使いたいですよね！？ 7

背景 「社内で手軽にHTTPSを使いたい！」 • 開発環境でもHTTPSを使いたい場面は割とある • e.g. モバイル開発、QA、社内システムのHTTPS運用 • そこで、各開発者が証明書を発行することなくHTTPSを利用するため、 生産性向上チームは開発用DNS基盤を開発・運用してきた • 開発用DNS基盤とは、SSLリバースプロキシとRoute 53からなる基盤 社内VM上に建っていた HTTPS 開発者 HTTP リバースプロキシ サーバー 8

背景 リプレイスのモチベーション • リバースプロキシが著しく老朽化していた • OS: Ubuntu 14.04.5 (2016/08/04) 最新バージョン Ubuntu 25.04 (2025/04/17) Keepalived 2.3.4 (2025/06/10) Redis 8.0.0 (2025/05/02) • ミドルウェア: Keepalived 1.2.7 (2012/08/29)、 Redis 2.8.4 (2014/01/14) • これらの継続的なバージョンアップは難しかった 開発のみの使用だったので 優先度が上がらなかった • Keepalivedの学習コストの高さ、チームの忙しさ • 運用コストを下げるため、マネージドなサービスを利用したくなってきた • 接続したいサーバーは社内ネットワーク内にあるため、そのサービスから 社内ネットワークに繋げられる必要もあった 9

背景 リプレイスのモチベーション 最新バージョン Ubuntu 25.04 (2025/04/17) Keepalived 2.3.4 (2025/06/10) Redis 8.0.0 (2025/05/02) • リバースプロキシが著しく老朽化していた • OS: Ubuntu 14.04.5 (2016/08/04) • ミドルウェア: Keepalived 1.2.7 (2012/08/29)、 AWSの出番！ Redis 2.8.4 (2014/01/14) • これらの継続的なバージョンアップは難しかった • Keepalivedの学習コストの高さ、チームの忙しさ • 運用コストを下げるため、マネージドなサービスを利用したかった • 接続したいサーバーは社内ネットワーク内にあるため、そのサービスから 社内ネットワークに繋げられる必要もあった なお、AWSから社内ネットワークへの 経路は確立済みだった 10

リプレイスの概要 11

リプレイスの概要 旧開発用DNS基盤におけるSSL化の仕組み（準備） foo.example.com経由でサーバーにHTTPS通信する場合 UI付きDBをノーコードで 作れる的なサービス 1. fooと192.0.2.1の組を登録 2. foo.example.comから proxy.exampleへの CNAMEレコードを作成 3. 1の組を登録 NGINX 開発者 リバースプロキシ （proxy.example） 開発用DNS基盤 サーバー （192.0.2.1） 12

リプレイスの概要 旧開発用DNS基盤におけるSSL化の仕組み foo.example.com経由でサーバーにHTTPS通信する場合 4. foo.example.comを 名前解決 5. HTTPS通信 開発者 6. fooに対応する IPアドレスを取得 NGINX 7. HTTP通信 リバースプロキシ （proxy.example） 開発用DNS基盤 サーバー （192.0.2.1） 13

AWSにどうリプレイスする？ 14

リプレイスの概要 リプレイス戦略（1/2） NGINX 開発者 リバースプロキシ サーバー 開発用DNS基盤 15

リプレイスの概要 リプレイス戦略（1/2） 開発者 リバースプロキシ サーバー 開発用DNS基盤 16

リプレイスの概要 リプレイス戦略（2/2） • 旧リバプロのアーキテクチャをAWSでそのまま再現する方針でリプレイス • 元々のアーキテクチャで特に問題が発生していなかったため 実はALBやLambdaが いたりもする 開発者 リバースプロキシ 開発用DNS基盤 サーバー 17

技術選定まつり 18

技術選定まつり リバースプロキシはどうやって用意する？ • 最終的にはECS×Goで実装した • リバースプロキシを実装するための標準ライブラリが提供されているから • net/http/httputil.ReverseProxy • 他に検討した案 • Nginxの利用: Nginx上で動作するLuaプログラムとElastiCacheの噛み合 わせが悪く、また生産性向上チームにNginxとLuaの知見があまりなく断念 • ALBの利用: ターゲットグループの数（ルーティング先の数）の上限が100 で、検討時に有効だったホスト数は約500だったので断念 • AWS Lambdaの利用: リクエスト・レスポンスのペイロードのサイズ上 限が20MBで、それより大きなペイロードが存在していたので断念 19

• https://pkg.go.dev/net/http/httputil

技術選定まつり キャッシュはどうやって用意する？ • サーバーレスなElastiCacheを採用 • 旧リバプロではキャッシュとしてRedisを採用しており、Redis互換な サービスを利用したかったから • Redis互換のValkeyを実体として使用 • サーバーレスを採用しているのは、細かい設定をAWSにオフロードして 運用を楽にするため • 他に検討した案 • MemoryDBの利用: 耐久性はElastiCacheより優れていたが 今回は多少のデータロストを許容できたので、料金の高さから断念 DBのマスターがkintoneだから 20

とある事件 21

とある事件 ダウンタイムなしに新リバプロへ切り替えたぞ！ そのとき…… ある社内システムにアクセスできません…… 毎日多くの社内開発者に利用されるめちゃ大事なシステム 22

とある事件 ダウンタイムなしに新リバプロへ切り替えたぞ！ そのとき…… 障害発生！ ある社内システムにアクセスできません…… 毎日多くの社内開発者に利用されるめちゃ大事なシステム 23

とある事件 原因と対策 • 原因 • AWS上のリソースからの一部通信が社内ファイアウォールで阻まれること • 対策 • 仕様を変更し、リバースプロキシを利用可能なサーバーは 社内ファイアウォールに阻まれない場所に位置するものに限定した • 影響を受けるサーバーは、約500個中10個だったため • ただし、継続利用が必須なもの（e.g. 利用者が多いもの、GPUを積んでいるもの）は 社内ファイアウォールに穴を開けてもらって通信を許可した • 新リバースプロキシがデグレしていないことを入念に確かめた • リバースプロキシを利用する全てのサーバーに対して、新旧プロキシの レスポンスボディが一致することを確認 24

とある事件 訪れた平穏 • 2度目の切り替え以降は、特に障害が発生せず！！！ • 「ヘッダーの値が少し違うけど意図通り？」みたいな連絡が一回来ただけ • 旧リバプロも爆破済み • 安心して眠れる日々…… Goo … t h g d Ni 25

まとめ • 「社内で手軽にHTTPSを使いたい！」を支えるシステムを生産性向上チーム は開発・運用していた • そのシステム（特にSSLリバースプロキシ）が老朽化していたので AWSにリプレイスした • AWSでリバプロを実装する場合、ECS×Goが良い選択肢だった • 旧リバプロから新リバプロに切り替える際、障害が発生しちゃったぜ！ • 社内ファイアウォールに通信が阻まれることが原因だった • リバプロの仕様を変更して対処した • デグレしていないこともより入念に確認した 26

おまけ（補足資料） 27

おまけ（補足資料） プロジェクト体制・プロジェクト期間 • プロジェクト体制 • 3人（Show含む） • 途中でメンバーの増減はあった • 基本的にモブプログラミングで開発 • プロジェクト期間 • 2024年8月ごろ〜2025年1月ごろ 28

おまけ（補足資料） 新しい開発用DNS基盤のアーキテクチャ図（詳細版） AWS Cloud Virtual private cloud (VPC) Private subnet Private subnet ECS Tasks 社内ネットワーク ・・・ 29

おまけ（補足資料） kintoneから組を変更・削除した場合はどうなるの？ • Route 53とElastiCacheに登録されている内容も変更・削除される • なお、kintoneの登録内容は、定期的（10分ごと）にRoute 53とElastiCache へ同期される • 実行環境は、それぞれGitHub ActionsとAWS Lambda • 実行環境が異なる深い理由はない • GitHub Actionsに関して、Route 53への同期は元々それを用いていたから • AWS Lambdaに関して、選定理由マジで覚えてない……（バイブス？） 30

おまけ（補足資料） なんでホストごとにリバースプロキシへのCNAMEレコードを作成するの？ • foo.example.comとbar.example.comを同じリバプロに接続させたいなら、 *.example.comからリバプロに向いたレコードを作ればええやん、kintoneへ の登録のたびにレコード作らんでええやん、という疑問 • 回答: なんでやろ…… • 発表資料を作ってて気づいた、ワイルドカードレコードでいいかも • 一方で、開発用DNS基盤はHTTP通信もサポートしている • 開発者はHTTP/HTTPS通信どちらか一方のみ選択可能 • HTTP通信の場合、リバースプロキシを経由させたくないため、foo.example.comか らサーバーのIPアドレスへのAレコードを作成している • なので、Route 53へのレコード登録は結局必要だからどっちでもよさそう 31

おまけ（補足資料） 新旧リバプロのダウンタイムなしのマイグレーション • やりたいことは、Route 53に登録されたCNAMEレコードの向き先を 新しいリバプロに変更すること • いくつか方法がある • 加重ルーティング • ローリングデプロイ的なことができる • ChangeResourceRecordSets • 複数レコードをアトミックに変更できる • 今回は後者の方法を採用した • 定期的に行うRoute 53の同期と同じロジックが利用できるため 32

• https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html

©️ Cybozu, Inc. 62