koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

見せてもらおうか、RDSのBlue/Greenデプロイの性能とやらを

先立つ2025年1月20日に以下のようなAWSのRDS Blue/Green Deploymentsについての記事が出た。

aws.amazon.com

なんでも、RDS(やAurora)をBlue/Greenデプロイで切り替える際のダウンタイムが5秒未満になるのだとか。

「マジ?」

どういう理屈でそうなるんだ? ということは、この辺から類推できるようなできないような。

Switching a blue/green deployment in Amazon RDS - Amazon Relational Database Service

Make sure that your network and client configurations don’t increase the DNS cache Time-To-Live (TTL) beyond five seconds, which is the default for RDS DNS zones.
 Otherwise, applications will continue to send write traffic to the blue environment after
 switchover.

DNSがちゃんとTTL通りに名前解決するようにしろ。ここに5秒というキーワードがある。

ということで、ちょっとBlue/Greenデプロイ時のDNS応答の様子を眺めてみた。

サンプル

サンプルはAurora for MySQLクラスタエンドポイントのホスト名で問い合わせたもの。

Blue/Greenデプロイを作る前

CNAMEレコードでWriterのホストを返すのを経由して、WriterのIPアドレスを解決している。

ここではTTLは60秒。

AWSの名前解決はALBなどのエイリアスレコードの場合も60秒なので、TTL60秒が標準なのだろう。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 60 IN CNAME hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com. 60 IN A 172.31.12.95

Blue/Greenデプロイを作った後

応答内容は同じでTTLが5秒になった。

なるほど。これで行儀がよいクライアントなら5秒未満で接続先を切り替えることができるわけだ。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.31.12.95

Greenに切り替えた後

CNAMEレコードがGreenのWriterのものになった。

ちゃんとTTL通りに接続先を解決しなおしていれば、5秒未満で接続先が切り替わる。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME hoge-ap-northeast-1c-green-yyyy.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-ap-northeast-1c-green-yyyy.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.31.10.119

Blue/Greenデプロイを削除した後

CNAMEレコードがデプロイ前と同じものになるが、それが示す先はB/Gで切り替えたものと同じになっている。

TTLは5秒のままだが、少し待ってから再問合せしたらいつの間にか60秒になっていた。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME hoge-ap-northeast-1c.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-ap-northeast-1c.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.31.10.119

所感など

5秒未満のダウンタイムになる理屈はなんとなく分かった気がする。

実際には名前解決以外にもBlueへの問い合わせ失敗から再接続までのオーバヘッドなどがある、この理論値通りにはならない。

別にAWSの回し者ではないが、理論値に近づけたければRDS Proxyを挟んだり、チューニングされた接続ライブラリを使うのが良いのだろう。

この動作に最適化されているAWS公式のJDBCドライバはこちら

同日に最新版がリリースされているので、ガチでチューニングする際の参考になるのかもしれない(詳しくは見ていない)。

github.com

timesページのサムネイル遍歴 2025

2025年のテンアゲ画像

去年チームのナレッジベースの個人ページのサムネイルを並べた記事を書いた。

koudenpa.hatenablog.com

勤務先の所属チームのナレッジベースには主にScrapboxが使われている。

毎月個人的なメモ等を雑多に書く「城」ページを作っているのだけれど、一覧上で識別しやすい画像がサムネイルになるようにしている。

どうせなら気分がアガる画像がいいので、その時々に作ったプラモデルや、開封したフィギュアなどの立体物の写真を「テンアゲ」画像として貼っている。

何とまだ続いているので更新差分を記録しておく。

  • 2025(と2024/12)
    • 2024/12
    • 2025/1
    • 2025/2
    • 2025/3
    • 2025/4
    • 2025/5
    • 2025/6
    • 2025/7
    • 2025/8
    • 2025/9
    • 2025/10
    • 2025/11
    • 2025/12
  • 傾向
続きを読む

プラモとIT

このブログのカテゴリーにプラモデルがある位にはプラモ、模型が好きで、公私でプログラムする位にはITに携わっている。当然、この二つの関わりにも興味がある。今回はその辺り消費者から見た現状への雑感をメモする。

これははてなエンジニア Advent Calendar 2025の13日目です。 前日は id:gurrium さんの「SwiftUIで様々な行 - ぜのぜ」でした。

ギリギリになってから書こうと思っていたところ、体調を崩して遅刻してしまった。 30MM ARMORED CORE Ⅵ FIRES OF RUBICON ARQUEBUS ADD VE-40Aを買いにヨドバシカメラに並びに行くのも見送らざるをえなかった。無念。

  • 共有、発信
  • 制作のサポート
  • デジタルとアナログ
  • 生成AI
  • 雑感の雑感
続きを読む

GitHub Copilot coding agentにWebサービスを作ってもらう

しばらく前から「趣味のコンテンツ消費の感想を溜めたいなぁ」と思っていた*1のをできるようにしてもらった。

前世代のAIモデルと別の技術スタックで挫折していた*2のを、2025/10月現在のAIエージェントでやり直した形。最低限の用が足りるものが出来た感がある。

その作ってもらった記憶が残っているうちにメモしておく。

ちょいちょい見かける「人の介入なしに生成AIに何かを作ってもらう」例になるかと思う。

※2025/10月現在のGitHub Copilot coding agentの体験なので、他のツールやモデルでは違う体験になるかと思う

  • 何をどう作ってもらったか
    • 何を
    • どうやって
    • どうなった
    • やってもらってないこと
  • 所感
    • 非同期開発&他職種目線
    • エンジニア感のある指示では想定を超えてこない
    • 得意不得意
  • この後
    • 余談としてやると体験が良さそうだったこと

*1:映画や読書の感想など特定のコンテンツの種類の感想を溜めるサービスはあるけれど雑多にごった煮なサイトは見かけないので、、、

*2:残骸: https://github.com/7474/ShumiLogDotNet

続きを読む

生成AI仕様駆動開発所感

生成AIでの仕様駆動開発ツールは趣味で使いたいものではなかった。

ので所感を記録しておく。

使ったのはGitHubのSpec Kit。 モデルはCloude Sonnet 4、GPT-5-Codex、Gemini 2.5 Pro辺りを気分で使い分けていた。

github.com

  • 遅い&トークン消費が速い
  • レビューがダルい
  • 英語の壁
続きを読む

生成AIにプラモの塗装プランを作ってもらう~ランス6 ウルザを見立てる~

日頃プラモデルを組むにあたって、大体はパチ組か部分塗装をしている。

公式なカラーチャートは存在したりしなかったりするので、いつでも参考にできるわけではない。キットとは別な色を塗ろうとしたらチャートがあるはずもない。

といったところで、ぼちぼち生成AIの画像分析がなかなかいい感じになっているので、Geminiに画像を渡してどの塗料で塗ればいいかの参考情報を出してもらった。

‎Gemini - キャラクター塗装プラン最終塗料表 (コードブロックは中身の抜粋)

以下の条件で、添付画像に描かれたキャラクターを塗装するための「最終的な塗料表」を作成してください。

【条件】
1. 画像から各パーツ(帽子、衣服、髪、肌、装備、アクセント等)の代表色を抽出し、RGB値を提示する。
2. 抽出したRGB値を基準に、GSIクレオス「水性ホビーカラー(レギュラーカラー)」の中から最も近い色を第一選択肢として選定する。
3. 第一選択肢の色番号と正式色名を明記する。
4. 必要に応じて微調色の目安(例:H◯◯を5%混ぜる)を記載する。
5. 第一選択肢が入手困難または発色が合わない場合に備え、代替候補(ファレホ、シタデル等)を1〜2種併記する。
6. 出力は以下の列を持つ表形式とする:
   | 部位 | 目標RGB(カラーコード) | 水性ホビーカラー(第一選択) | 第一選択RGB(カラーコード)| 目標RGB(プレビュー)  | 第一選択RGB(プレビュー)  | 微調色の目安 | 代替候補 |
7. RGB値は画像の代表画素を参考にし、近似値でよい。
8. 色選定は公式カラーチャートのRGB値や色見本を参照し、RGB距離(ΔEやユークリッド距離)を考慮して最も近い色を選ぶ。
9. 色のプレビュー列にはGoogleスプレッドシート上で色をプレビュー表示できる数式を設定する。
10. 最後に、塗装時の下地色やトップコートの推奨(つや消し/半光沢/光沢)を簡潔にまとめる。

【出力例】
| 部位 | 目標RGB(カラーコード) | 水性ホビーカラー(第一選択) | 第一選択RGB(カラーコード) | 目標RGB(プレビュー) | 第一選択RGB(プレビュー)  | 微調色の目安 | 代替候補 |
|------|---------|-----------------------------|--------------|----------|
| ベレー帽(明るい緑) | #5C9E55 | H46 エメラルドグリーン  |#61AA90 | =IMAGE("https://dummyimage.com/100x30/5C9E55") |  =IMAGE("https://dummyimage.com/100x30/61AA90 ") | 黄味を足すならH50を5% | H50 よもぎ色/ファレホ 70.970 ディープグリーン |
...(以下続く)
※数式はコードブロックとせず、エクスポート時に数式として処理されるようにする

ところどころ怪しい気もするが、なかなかそれらしくやってくれているのではないか。少なくとも参考にはなる。

これを参考にジャケットをH46エメラルドグリーンで塗った30MSなんちゃってランス6ウルザを塗った。

ハイレグオプションパーツとジャケットっぽい袖を入手したら組もうと思っていたところに、たまたま30MS オプションパーツセット17(エイダーコスチューム)[カラーA]を買えたのでな。

靴底がはがれるほどの激戦だった模様

ん~~~、大分色違うな~~~。もうちょいボリュームのあるジャケットとかそれっぽい手足とかを入手出来たらリトライを考えよう。とにかく手足全く流通してないからなぁ。とりあえずはこんなもんで。

今回サイズ(体形と言ってもいい)違いのパーツを組み合わせているのだけれど、やはり隙間が広く空いてしまう(特に股関節)。30MSは肌の色は商品名に表記があるけれど、体形は(多分)明記されていないのが不親切だと思う。パッと見だと互換性が分からない。

AWSコンソールにくっついているQが結構よい

AWSをブラウザ上から管理するAWSコンソールにはだいぶ前からAWSの生成AIである『Q』を呼び出すチャットが統合されている。

画面右上に呼出しボタンがある

リリースされてからかなり長い期間英語のみの対応で「AWSは生成AIを普及させる気あるんか?」くらいにイラついていたのだけれど、日本語対応してからはちょいちょい使っていて、結構いい感じだなと思う。

生成AIがサービスのアシスタントとして自然かつ効果的に統合されている。

特に何もしなくとも、AWSのリソースの状態を確認したり、取りたいアクションについての推奨を提示してくれる。これらは「お手元のエージェントに正しくMCPを統合すればいいじゃん」という話もあるかも知れないが、なにも意識しなくてもAWSを触っている時に知りたかったりやりたかったりすることをサポートしてくれるのはとても体験がよい。

現在のログイン、表示状態に基づいた調査や情報源を示してくれるし、

APIを叩いて情報収集してくれる

AWS CLIスニペットも動くものが提示されることが多い。

変数がある場合などはAWS CLIスニペットを提示してくれる

ボタンを押せばCloud Shellにスニペットが流し込まれるのも素朴に便利だ。

スニペットはCloud Shellで即座に実行できる

無料版でここまで便利でいいのか? と思ってしまう。そのくらいには触感がいい。

AWSを使っていて、触れていない人は是非試してみて欲しい。

特に落ちはなく、単に今現在のAWSコンソールのQはいい感じだな、という感想でした。