どうなるか、どうするか。
どうなるかというと、全店舗でプライマリな注文フローが機能しなくなる。これは大変だ。
とはいえ、インターネットを介して注文を受け付けるフローとしていたなら、その受け口となるWebサービスのダウンは想定していて然るべきだろう。 大手ならそうした状況に対応する手段をマニュアル化して整備してあるはずだ。
ソフトウェアエンジニアとしては、そうした際に備えた設計がどのようなものであるかを想像したい。
- 業務を続けるか？
- 分散システムの境界
- エンジニア脳
- 答え合わせ
Azure嫌になっちまったな —— 趣味の拠点をAWS CloudFrontへ移す話
Azure CDNが来年廃止になることは認識していたのだけれど、それより1年以上早く「証明書の更新止めるから実質使えなくなるよ」と案内が来たのでしぶしぶAWSのCloudFrontに移行していた。
来年までは放置のつもりだったところに嫌な不意打ちである。
かなりムカついているのだけれと、ムカつきを記事にするほどのエネルギーもないのでCopilotGeminiだったに代弁してもらった。
代弁内容には欠片も思っていないことも含まれているけれど、ホビーユースではAzureでCDNを使えなくなったこと、他の部分からもエンタープライズ志向が強くなっていて日曜プログラムには使いづらくなっていっていることはとても寂しい。
世のAzureホビーユーザーはどういう気持ちでいるのだろう。
料金 - Content Delivery Network (CDN) | Microsoft Azure
phpMyAdminをAWSのLambda関数URLで動かす
phpMyAdminをAWS App Runnerで運用している。VPCに繋がって、メンテナンスフリーで、低コスト、とそのくらいの用途には丁度良かったのだが、この度新規のサービス立ち上げが終了することになった。
App Runnerを使っている人には周知の事実として、サービスが壊れやすく、壊れたら復旧できず新規にサービスを作り直すしかなくなることがある。
つまり？ 更新にしくって壊れたら一環の終わり。
終了の案内には移行先としてECS Expressが提示されているが、ALBだけでApp Runnerの最小コストをぶっちぎって行くほどのコスト差がある。
AWSでWebアプリケーションを低コストなコンテナホスティングするには？ Lambda関数URLになるだろう。API Gatewayすら置きたくない！
というわけで、CopilotにphpMyAdminの公式イメージをLambda関数で動くようにラップしてもらった。
詳しくはリポジトリのREADMEにCopilotが書いたノートがある。一応校正はした。
手元の環境ではなんとなく動いている。これでApp Runnerが壊れても安心だ！？
Aurora for MySQL r6g to r8g のパフォーマンス変化例
先日、昼の仕事でAuroraのインスタンス世代を上げると相応に性能が上がる、のような記事を書いた。
その記事を書いているときに別件でこのブログに（規模は小さいが）同様の事例を書いていた気がしていたのだけれど、見当たらなかったので気のせいということにしていた。
ついさっき下書きを眺めたらそれらしいメモが転がっていたので公開しようと思った次第。
本編より前置きの方が長いが大丈夫か？
以下は下書きほぼママ、下書きと言うよりはメモか残骸と言ったほうが正しいかもしれないが、1例として多少の価値はあるだろう。多分。
なお、インスタンスサイズはxlarge。前後で変更なし。
CPU使用率にめちゃくちゃ余裕があるのはガチピーク負荷基準でRIを買っているから。これ、リニアにスケールしたい。が、Serverless v2比では全然安い。Auroraのリソース効率はムズい*1。
メトリクスを眺めたのでWebアプリケーションの実測での参考として記録しておく。
性能が向上していた項目
CPU使用率以外は誤差の範囲だが、多少傾向としてレイテンシが下がっている項目があった。
CPU Utilization: 30~40%程度使用率が低下
宣伝上はr6g->r7gで最大30%、r7g->r8gで最大40%処理能力向上
- Amazon Aurora が新たな AWS リージョンで R7g データベースインスタンスのサポートを開始 - AWS
- Amazon Aurora が Graviton4 ベースの R8g データベースインスタンスのサポートを開始 - AWS
まあまあそれらしく性能向上しているのではないか？
Select Latency: 1.5ms->1ms程度
Commit Latency: 2.8ms -> 2.5ms程度
この辺は誤差かな。 元々の負荷が低いのだろう。
VPS1台で動いていたLAMPなLaravel5をServerlessなLaravel12にした
VPS1台で動いていた10年物のWebアプリケーションを、AWSのサーバレス環境にした例のメモ。
そのうち移行が必要なことは何年も前から分かっていたのだけれど大分億劫だったのが、昨今の生成AIを使えばそんなに手間をかけなくても移行できるのではないか？ と思って試して、実際さほど手間をかけなくても移行できた気がしている。
PHPのコードが数千行程度の小規模なものなので手でやっても手間は大差なかった可能性もあるが、生成AIがきっかけにはなったので助かった。
- ワンチャンCopilot Coding Agentがやってくれないか？
- 生成AIでの移行感
- Laravelのアップグレード
- ファイルアップロード先の変更
- Serverless Frameworkの構成
- フロントエンド
- まとめというか小並感
この半年の生成AIの仕事ぶりの成長に感動した
Claudeなら4.0から4.6のモデル世代差。
「感動した」という感情を発露しているだけで、ナレッジなどは特にないお気持ち記事です。
GitHub Copilot Coding Agentにアプリケーションの言語間移植進行について、現状の進行状況を棚卸しし、完了までの計画を立てて貰っていた。
過去には棚卸しが全く行えず、架空の機能を列挙して完了を目指す激しいハルシネーションが発生していた。 一方で直近の世代では実際の進行状況、存在するTODOや機能を正しく列挙し、完了を目指すため計画を立てることが出来た。 そして、移植進行を指示することで実際に残余のTODOが消化されていった。
特別な工夫をしなくても、実際的な仕事を行えるようになったと感じる。 このパラダイムシフトは凄い。AI驚き屋になってしまいそうだ。
- 過去の機能しなかった様子:
- 直近の機能した様子:
半年前の指示 最近の指示
一方で「移植が正しく行われたか？」は未検証で、あくまでコードベースで「一見移植した」だけに過ぎない。
妥当性を検証する必要がある。
今後の生成AI活用に当たっての鍵は、この総合的な検証をどう行うかになってくると思う。
人間が妥当性を確認していてはそこで律速することは目に見えている。
いかに生成AI自体が総合的な検証を行えるようにするのか？ これが大事になってくるだろう。
