構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

JAWS-UG 茨城 #11 CDK 支部コラボ回 セッション登壇枠参加+筑波山(ちょっとだけ)詣で(2/1)

今年 2 箇所目の遠征でした。

jawsug-ibaraki.connpass.com

直前のドタバタ

数日前に登壇ネタレギュレーション問題が発覚

「茨城でも CDK でもないネタならセッション登壇枠(20 分)だな」と思ってセッション登壇枠に申し込みましたが、概要を読んだらしっかり「茨城と CDK をテーマに」と書いてありました。

(当日現地で確認したら「全然問題ないです」と言われたので安心しました)

並行して体調問題が

前週の月曜日あたりから耳閉感が出てきて水曜日に耳鼻科にかかるも症状は酷くなり、耳鳴りも出てきたので土曜日に再度耳鼻科へ行ったところ、右耳の低音障害型感音難聴が再発していました。

とりあえずつくばには来たので半日観光

当日の午前中はあちこち歩くつもりでプランを考えていたのですが、あまり歩きすぎると難聴が悪化しそうなので極力歩く距離を減らして筑波山神社へ。

バスを降りて神社に向かう途中に大御堂があったので寄り道。

池に氷が張っていました(写真 2 枚目)。

その後先へ進んで筑波山神社へ。

実は先月の BuriKaigi 2026 で撮影スタッフをしたときに登壇者+スライド表紙の撮影で惨敗した反省(?)を踏まえて「明るいレンズでも背景がボケにくい」マイクロフォーサーズのカメラと開放 F2.8 のレンズを調達し、今回「お供」として持ってきたので試しに石段下の御神橋をパチリ。

筑波山神社御神橋 [1]

比較的明るい場面だったこともあり F6.3 で撮れたので背景はほとんどボケず。

(ボケなかったので花粉症の人が気になりそうなものが背景にバッチリ写ってしまった)

続いて裏側にまわって梅の花にピントを合わせて撮ってみます。

筑波山神社御神橋 [2]

半逆光でしたが F5.6 で、御神橋の屋根はよく見ないとわからない程度にしかボケませんでした。

この後もいろいろ撮ってみましたが、普段使っている APS-C のカメラ+明るめのレンズ(開放 F2.0 以下)とは違って(夜間のように本当に暗いシーンでない限り)絞りオートではやや絞り気味の選択となり、スマホコンデジに近いパンフォーカスな写真が多くなりました。

常夜燈と随神門

筑波山神社の屋根

室内だともっと開放寄り(F 値低め)になるはずなのでもう少し注意が必要そうですが、登壇者+表紙スライドを写すとき、APS-C 機よりは失敗の確率は下がりそうです。

コンデジは広角側でないとレンズが暗いことが、スマホシャッタースピードの細かい調整が難しくプロジェクター投影との相性が悪いのが問題)

参拝を終えて、時間も体調も余裕があったのでケーブルカーで筑波山の山頂駅周辺まで昇ることにしました。

大御堂の池が凍っていたように早朝は氷点下だったこともあり、山肌からうっすら霧が出ていました。

ワッフルとラテをいただく

むかしむかしのマスコンとブレーキハンドル

ケーブルカーの運転台は山上駅側にあって車体にはないので、マスコンもブレーキハンドルもデカかったんですね。

JAWS-UG 茨城に参加

前置き(?)が長くなってしまいましたがここからが本編(?)です。

お昼に下山してつくば駅に戻り、少し早めに会場入りしました。

各セッション・LT(10 分トーク)について一言ずつ

今回、事情により「ミニ LT 枠」が急遽誕生し、結果的にトークの本数が増えたので短めにコメントさせていただきます。


speakerdeck.com

Control Tower 自体がある意味「IaC の代わりに色々な設定をよしなにまとめてやってくれる機能」という認識だったのであまり IaC で管理する発想はなかったのですが、確かに初期設定ではなくて使い始めてからの変遷は差分管理したいかな?と思いました。

そして「API では対応していない機能がある」というのは初耳でした(「リージョン拒否コントロール」自体はおそらく SCP を組み合わせて実現していると思うので、頑張ればできないこともなさそうですが)。


speakerdeck.com

このあたりの内部処理の話もあまり考えたことがなかったので新鮮でした。

プログラミング視点で考えると、遅延評価が必要な場面での実装を考えるときに参考になりそうですね。


ここから 3 本が件のミニ LT 枠でした。

www.docswell.com

ハンズオンの開発環境として使う VS Code Server の構築で躓く話、「世の中のほとんどのプログラミング挫折者は開発環境の構築ができずに挫折する」のにつながる話でわかりみが深かったです。

catalog.workshops.aws

speakerdeck.com

DevOps Agent、まったく触っていなかったのでプレビューのうちに一度試してみたいと思いました。

(機能によっては GA でガラッと変わってしまうケースもあってちょっと怖いのですが)

speakerdeck.com

(この資料の ICASU 部分から抜粋)

ICASU、うっかり存在を忘れかけていましたが、主に新規での典型的パターン構築時の参考になりそうなので活用したいと思います!


speakerdeck.com

CodeCommit の復活がガバクラに影響していることについては全然認識していなかったので「そんなところにも影響するのか!」(言われてみればそのとおりだけど)という驚きがありました。

あと「GitHub の関連サービスだけど GitHub そのものじゃないやつ」(GitHub Enterprise Server とか)の細かい制約の違いなどもいろいろ面倒なんですよね…。


speakerdeck.com

最初のいたくらさんの話とも共通しますが、「変更点の確認」「変遷の確認」、あるいは「変更時の構成の問題点の確認と修正」などをするときに IaC が役立つことを再認識しました。


habuchin.github.io

個人開発など資金が少ない状態でサービスを始めるとか、そもそも最初からマネタイズを考えないケースとかでは意外と AWS を選びづらくて別の構成を選ぶことになるのは、他に実例をたくさん見てきているのでよくわかるお話でした。

そしてそのケースで DB がネックになる点もよくわかります(無料枠がなくなってしまったサービスもありましたね)。


CDK でクォータ制限解除申請を出せることを認識していなくて新たな学びになりました。

1 回限りならともかく何度もやらないといけないケースでは(マルチテナントかどうかにかかわらず)活用できそうです。


speakerdeck.com

個人的にはフロントエンド(すでにクラスを使わなくなってきた時代)から TypeScript に入門したので、実は CDK の TypeScript にはあまり慣れていないのですが、同じ言語を使うことで開発環境がある程度共通化できると、「初心者が開発環境の構築で挫折する問題」を(ある程度)軽減できる点から考えてもメリットがありそうな感じがしました。

自分のセッション

www.docswell.com

直前のドタバタ劇はありつつも、結果的に皆さんに楽しんでいただけて良かったと思います。

内容自体は別件登壇 2 つをまとめてダイジェスト版として再構成したものにアレンジを加えただけですが、ネタとして持ってきた甲斐がありました。

完全に後付けで茨城(つくば)と IPv6 の話を結びつけましたが、ちゃんと反応があって良かったです。

オフィスや家庭のネットワークが対応していないケースは多いのですが、サービス提供側がクラウドのマネージドサービスを使うケースが増え、ユーザーの端末がモバイル中心になった結果、知らないうちに IPv6 で通信しているケースが実感以上に増えているようです。

このあたりは説明がちょっと難しくて、本来の IPv6 には IPv4 のプライベートアドレスと全く同じ立ち位置のアドレス空間は存在しないのですが、近い目的で使えるものに IPv6 ULA(ユニークローカルユニキャストアドレス)があり、それに加えて AWS では(持ち込み IPv6 アドレスに限定して)GUA(グローバルユニキャストアドレス)をプライベート化する機能が実装されています(「プライベート化」といっても IPv6 同士での NAT が AWS 標準のサービスだけでは実現できないので、IPv4 におけるプライベートアドレスと全く同じ立ち位置ではありません)。

セッションで触れましたが「現状の CDK で IPv6 VPC を構成するのに L2 Construct とちょっとしたエスケープハッチだけで実装することは意外と困難」な点には注意が必要ですね。

(ある VPC・サブネットの構成では L2 + エスケープハッチで行けるが、別の VPC・サブネットの構成でそれをやろうとすると L1 ベースや CFn よりも内容の読み解きが難しくなってしまう。そして両パターンの VPC・サブネットが混在する環境を作る場合にコードの統一性がなく内容の読み解きがさらに難しくなってしまう)

懇親会

「推しのサービスを他人には推せない」話が出たところで「私にとっては MySQL がまさにそれ」という話を返したところから昨今のデータベース事情の話題になったり、IPv6 の話から「遠い昔の大学・(主に研究施設などを持つ)製造業の IPv4 アドレスの使い方(そもそもプライベートアドレスが存在しない時代に広大なアドレス範囲を取得して施設内の機器に割り振っていた)」などの話題になったりで、私が座ったテーブルでは AWS にとどまらない技術の話が展開されました。

名残惜しかったのですが帰りの時間もあり一足お先に離脱となりました。