---
title: 「社内で手軽にHTTPSを使いたい！」を支える化石システムのAWSへのリプレイス
tags: 
author: [Shoichi Sasaki](https://www.docswell.com/user/ajfAfg)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JZ6KPQXJ3.jpg?width=480
description: 「Engineering Productivity Meetup #4 in 東京」で発表した内容です。  https://cybozu.connpass.com/event/355795/
published: June 20, 25
canonical: https://www.docswell.com/s/ajfAfg/K22RL1-2025-06-20-195701
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JZ6KPQXJ3.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YE62QM6PJV.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GE52RZ6PE4.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/9724DRMZER.jpg)

背景
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/DJYM2DXNJM.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/V7NW861V78.jpg)

使いたいですよね！？
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YJ9XKL5VE3.jpg)

使いたいですよね！？
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJ82RXY4JD.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LJL2K84VER.jpg)

背景
リプレイスのモチベーション
• リバースプロキシが著しく老朽化していた
• 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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/47M826KN7W.jpg)

背景
リプレイスのモチベーション
最新バージョン
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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/P7R5MPX4J9.jpg)

リプレイスの概要
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/PJXKV36Z7X.jpg)

リプレイスの概要
旧開発用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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/3JK5QY1V7D.jpg)

リプレイスの概要
旧開発用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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LE3KP9NQE5.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/8ED3LGWW7G.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/V7P4239XE8.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/2JVXD4M37Q.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/5EGVY1GYEL.jpg)

技術選定まつり
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4JQ6MDX6JP.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/K744VZ6M71.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LJ143RVYJG.jpg)

とある事件
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GJWXP1L1E2.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4EZ6KPMXE3.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/Y762QMNPEV.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/G752RZ5P74.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/9J24DRNZ7R.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/DEYM2DPNEM.jpg)

おまけ（補足資料）
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/VJNW865VJ8.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/YE9XKLYV73.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/GE82RX64ED.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/LEL2K89V7R.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4JM826ZNJW.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/PJR5MP64E9.jpg)

©️ Cybozu, Inc.
62


