うぇぶこ

software engineer | career: SRE ◀︎ Backend ◀︎ Director & Frontend ◀︎ System Planning | Opinion is my own

[うぇぶこ @WebEngrChild]

"汎用AIのみで解く事が困難"という領域がSREエンジニアとして業務ど真ん中だな

[あんどぅ@育休中 @integrated1453]

NRIの株主総会の通知が送られて来たので中計2028の資料見たけど、投資家から見て「SIerの開発はAIに代替されるのでは？」という疑問に対して、「非機能要件が重要なんやで」という説明をしていて、NRIのテクニカルエンジニア出身の自分としてはグッと来るものがある
https://t.co/yQ3TlTigfS

[うぇぶこ @WebEngrChild]

よきー！安定感

[What's New on AWS (非公式) @awswhatsnew_jp]

Amazon Cognito が複数のリージョンでのレプリケーションをサポートするようになりました。

Amazon Cognito は現在、マルチリージョン複製をサポートしています。これにより、認証情報、ユーザープール設定、フェデレーション設定など、ユーザーおよびマシンアイデンティティデータを、指定したスタンバリリージョンにあるセカンダリユーザープールにほぼリアルタイムで同期することが可能になります。この機能により、地域サービスの中断が発生した場合にトラフィックを受け入れることができるスタンバリレプリカを提供することで、認証システムのレジリエンスを向上させることができます。プライマリリージョンで障害が発生した場合、トラフィックをセカンダリユーザープールにリダイレクトすることができます。サインインしているユーザーは再認証することなくアプリケーションにアクセスし続け、登録ユーザーは既存の認証情報でサインインすることができます。ユーザー名/パスワード、ソーシャルアイデンティティおよび SAML/OIDC プロバイダーとのフェデレーション、マシン対マシンの認証フローなど、認証方法はセカンダリリージョンでも引き続き機能します。マルチリージョン複製は、Essentials または Plus の機能ティアにあるユーザープール向けのアドオンとして提供されています。この機能は、以下の AWS リージョンで利用できます：US East (Ohio, N. Virginia)、US West (N. California, Oregon)、Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo)、Canada (Central)、Europe (Frankfurt, Ireland, London, Paris, Stockholm)、South America (São Paulo)。始めるには、レプリカユーザープールを追加して、AWS マネジメントコンソール、AWS コマンドラインインターフェイス（CLI）、または AWS ソフトウェア開発キット（SDK）を使用してマルチリージョン複製を構成してください。価格の詳細については 価格ページ を参照し、開発ガイド には手順が記載されています。

[うぇぶこ @WebEngrChild]

しれっと流してたけど結構良いアプデ

[What's New on AWS (非公式) @awswhatsnew_jp]

次世代のAmazon OpenSearch Serverlessが一般提供開始されました。

本日、AWSは、エージェント構築を目的とした顧客向けに設計された、完全マネージドの検索およびベクトルエンジンである「Amazon OpenSearch Serverless」の次世代バージョンの一般提供を開始しました。次世代のOpenSearch Serverlessは、前世代より20倍高速に自動スケールし、最も予測不可能なエージェントワークフローにも対応できるリソースを数秒でプロビジョニングします。スケールゼロと従量制料金により、ピーク時の負荷に対応するためのOpenSearchクラスターをプロビジョニングするコストと比較して、最大60%の費用削減が可能です。次世代のOpenSearch Serverlessは、新しい共有ストレージレイヤーを通じてコンピュートとストレージを完全に分離します。これにより、顧客はトラフィックが少ない期間にはコストを削減しつつ、トラフィックの急増に即座に対応できるように、コンピュートリソースを独立してスケールアップおよびスケールダウンできます。ネットワーク接続を簡素化するために、OpenSearch Serverlessはリソースベースのエンドポイントを2つ提供するようになり、これにより標準のVPC APIを使用して複数VPCおよびオンプレミス環境との接続が容易になります。次世代のOpenSearch Serverlessは、VercelやKiroなどのAI開発プラットフォームとのネイティブな統合を備え、開発者は自然言語コマンドを使用して開発環境から直接検索インフラをプロビジョニングできます。OpenSearch Serverlessは現在、OpenSearchエージェントスキルの一部としても提供されており、Claude Code、Cursor、Codexなどの人気のコーディングプラットフォームを使用する際に、OpenSearchの機能をエージェントに組み込むことができます。GA時点では、検索とベクトルが2つの利用可能なコレクションタイプです。次世代のOpenSearch Serverlessは、現在Amazon OpenSearch Serverlessが提供されているすべての商用AWSリージョンで本日より提供開始されます。次世代OpenSearch Serverlessの価格に関する詳細は、価格ページをご覧ください。次世代Amazon OpenSearch Serverlessの詳細については、マーケティングページ、技術ドキュメント、およびAWSニュースブログをご覧ください。次世代Amazon OpenSearch Serverlessに導入されたすべての新機能の詳細については、技術ローンチブログをご覧ください。

[うぇぶこ @WebEngrChild]

フロントエンドに携わっている人はマストで読んだ方が良い記事ですね

https://t.co/juFcat6aOW

[うぇぶこ @WebEngrChild]

子育てし始めてから中々趣味の時間取れないなーっ。空き時間にインプットして家事育児したら業務時間も休日も一瞬で終わる。子供が大きくなって親離れするまで今は我慢なのかな。

[Keisuke Nishitani @Keisuke69]

定期的に“沼れる”趣味を探してる。何かに一度ハマるとしばらく没頭する。主に道具揃える系の沼はやばい。やばいんだが、飽きるとまた次の沼を探す旅に出ている。また新しい沼を探している。最近これは沼だった、ってのある人いたら教えてほしい

[うぇぶこ @WebEngrChild]

最近この手の記事増えてきたなー。自プロダクト群でも検証してみたさある。以外とチリつもでもコスト削減効果あるからね。

https://t.co/hKkgkxcDYU

[うぇぶこ @WebEngrChild]

エンプラ規模での AI活用をガバナンスきかせて導入する上でめちゃくちゃ参考になる。
https://t.co/ADRhuUtT6p

[うぇぶこ @WebEngrChild]

お？なんか良さそうかも

[CodeZine @codezine]

GitHub、npmのサプライチェーン強化のため新機能を発表 https://t.co/7IzDD5sy7L

[うぇぶこ @WebEngrChild]

> EKSの設計・構築・運用をリードしていたKubernetesの有識者が社内異動でチームを離れることになり、

> マイクロサービスプラットフォームの運用メンバーは、私を含めて2名

この状況下でEKS導入に対してのGo判断がなされたとはねぇ...

https://t.co/aj9QMC7rGE

[うぇぶこ @WebEngrChild]

良いね https://t.co/geeaQfod9N

[うぇぶこ @WebEngrChild]

本業がむちゃくちゃ忙しいがここを乗り越えた先の景色を見てみたいので頑張る。業務時間の総量は変わらないけれど、密度の高さと意思決定の重さが最近すごいな。

[うぇぶこ @WebEngrChild]

おお面白い。DynamoDB専用に作ったアプリを、AWS外でもほぼそのまま動かせるって感じ?

[What's New on AWS (非公式) @awswhatsnew_jp]

AWSは、DynamoDB互換のオープンソースアダプターであるExtendDBを発表しました。

本日、アマゾンウェブサービス（AWS）は、Amazon DynamoDB APIを実装し、プラグイン可能なストレージバックエンドを備えたオープンソースプロジェクト「ExtendDB」のバージョン0.1を発表しました。Amazon DynamoDBは、任意のスケールで1桁ミリ秒パフォーマンスを実現する、サーバーレスでフルマネージドのNoSQLデータベースです。ExtendDBにより、アプリケーション開発者、プラットフォームチーム、エンタープライズアーキテクトは、開発者用ノートパソコン、オンプレミスデータセンター、切断されたエッジサイトなど、DynamoDBマネージドサービスが利用できない環境で、アプリケーションコードを書き直すことなくDynamoDBプログラミングモデルを使用できます。ExtendDBは、テーブル、アイテム、ストリームに対する操作を含む、DynamoDBの制御面とデータ面のAPIを実装しています。ローンチ時の参照ストレージバックエンドはPostgreSQLであり、プラグイン可能なアーキテクチャにより、コミュニティはコアアダプターを変更することなく新しいストレージバックエンドを追加できます。開発者は、ExtendDBを高忠実度のローカル開発や継続的インテグレーションテストに使用し、サポートされているデータベースをバックエンドとして、オンプレミスデータセンターでDynamoDB形式のワークロードを運用できます。ExtendDBはAWSによってメンテナンスされ、Apache 2.0ライセンスの下でリリースされ、GitHubでオープンに開発されています。コミュニティには、バックエンド実装の貢献、フィードバックの提出、プロジェクトの進化への参加を呼びかけています。詳細については、ExtendDBプロジェクトページおよびAWSデータベースブログ投稿をご覧ください。開始または貢献するには、GitHubリポジトリをご覧ください。

[うぇぶこ @WebEngrChild]

これは嬉しいのでは？

[What's New on AWS (非公式) @awswhatsnew_jp]

Amazon ECS では、サービスデプロイメントの一時停止および再開コントロールが導入されました。

Amazon Elastic Container Service（Amazon ECS）では、展開プロセスにおける重要なステージでサービスの展開を一時停止し、準備が整ったときに展開を再開できるようになりました。これらの一時停止ポイントを使用して、手動での承認ワークフロー、運用チェック、統合テスト、カスタム自動化などのシナリオに、手動の意思決定ポイントやインタラクティブな制御を導入できます。また、ネイティブなAmazon ECSの展開戦略（トラフィックの管理されたシフト、ベイク時間、迅速なロールバック、CloudWatchアラーム、展開サーキットブレーカーなど）を引き続き使用できます。

この新機能により、Amazon ECSサービスの展開設定の一部として、新しい「一時停止」展開ライフサイクルフックを構成できます。展開が設定された一時停止ポイントに到達すると、Amazon ECSは展開プロセスを一時停止し、Amazon EventBridgeイベントを発生させます。このイベントを使用して自動化ワークフロー、承認システム、または外部検証プロセスをトリガーできます。その後、新しいContinueServiceDeployment APIを使用して展開を再開またはロールバックできます。一時停止フックでは、最大14日間のタイムアウト期間と、アクションが受信されない場合に展開を自動的に再開またはロールバックするタイムアウトアクションを構成できます。

ローリング、ブルー/グリーン、リニア、カナリア展開戦略に対して、一時停止フックをAmazon ECSコンソール、AWS CLI、AWS SDK、AWS CloudFormation、AWS CDK、Terraformを使用して構成できます。ContinueServiceDeployment APIは、Amazon ECSコンソール、AWS CLI、AWS SDKを介して使用できます。この機能は、すべてのAWSコマーシャルリージョンおよびAWS GovCloud（US）リージョンで利用できます。詳細については、サービス展開の一時停止フックとサービス展開の継続に関するドキュメントをご覧ください。

[うぇぶこ @WebEngrChild]

20代は休日も技術関連のインプットとアウトプットに溶かしても無問題でしたが、30代になってから"意識的"に"無理をしてでも"土日は脳を休ませないと、平日のパフォーマンスが大幅に落ちたり、心身が不調になるので注意が必要だなーって最近思います。20代と30代は戦い方をシフトしないとって強く実感中。。

[みのるん @minorun365]

登壇資料一つ作るのに休日半日とかかけられてた時代が懐かしい。。なんか人生疲れてきたな…

[うぇぶこ @WebEngrChild]

20代は自分を過大評価し、環境のせいにして転職を繰り返しても学歴や勢いで通用した。しかし30代で年収800万を超えると、異業種転職しても結局は自分の能力の壁にぶつかり、環境を変えても本質は変わらないと理解し出す。市場評価と自己評価のギャップを直視し、今は現職で腰を据えて実力を積み上げる必要がある。

[うぇぶこ @WebEngrChild]

たぶんここに書かれていない何かが各社共通してNGなのでしょうね...これだけ見たら落ちるとは思ない。

[Kuro @tamagotake3454]

・空白期間なし
・次3社目だが各社2年は勤めてる
・割と難し目の資格持ってる
・TOEICも一応700はある
・運用保守とプログラミング業務経験が主
・国立理系院卒
・30手前

これで転職難航するのきびちい🫠

[うぇぶこ @WebEngrChild]

CDK勢には嬉しいかもね

[What's New on AWS (非公式) @awswhatsnew_jp]

AWS CloudFormation および CDK を使用して、アカウントやリージョンにわたるスタック出力を参照します。

AWS CloudFormationでは、新たに**Fn::GetStackOutput**という組み込み関数がサポートされるようになり、CloudFormationテンプレートやCDKアプリケーション内で、AWSアカウントやリージョンにわたるスタックアウトプットを直接参照できるようになりました。この新しい機能により、CloudFormationとCDKでのマルチアカウントおよびマルチリージョンなワークロードのプロビジョニングと管理が簡素化され、CDKアプリでのスタック間依存関係の再構成時に発生するデプロイのデッドロックが解消されます。マルチアカウントのAWS環境を管理する際、チームは多くの場合、VPC IDやデータベースエンドポイントなどのインフラストラクチャ値をアカウントの境界を越えて共有する必要があります。以前は、これを実現するにはテンプレート間で値をコピーしたり、チーム間でパラメータの更新を調整したりするなど、複数の手順が必要でした。今では、**Fn::GetStackOutput**を使用すれば、対象のスタック名、出力キー、クロスアカウントアクセス用のIAMロールARN、およびオプションでリージョンを指定するだけで済みます。CloudFormationは指定されたロールを想定し、出力値を取得し、テンプレート処理中に解決するため、手動での調整や設定のばらつきリスクが軽減されます。CDKアプリケーションでは、クロスアカウントおよびクロスリージョン参照がこの関数を使用して自動的に処理されるため、これまで必要だったカスタムリソースやSSMパラメータが不要になります。また、顧客は**Fn.getStackOutput**を直接呼び出してスタック間の弱い参照を作成でき、スタックのリファクタリングが簡素化されます。使い始めるには、CloudFormationテンプレートに**Fn::GetStackOutput**関数を追加し、クロスアカウントアクセスに適切なIAM権限を設定してください。CDKでは、クロスアカウントおよびクロスリージョン参照が自動的にこの関数を使用します。詳細については、AWS CloudFormationユーザーガイドまたはCDK開発者ガイドをご覧ください。

この機能は、CloudFormationがサポートされているすべてのAWSリージョンで利用可能です。サービスの可用性については、AWSリージョンの表をご覧ください。

[うぇぶこ @WebEngrChild]

X"いいね"や"ブックマーク"消えて焦っている皆さん。

新しくできた"履歴"にあります。

[yousukezan @yousukezan]

F5は13日、NGINX に深刻な脆弱性「CVE-2026-42945」が存在すると公表した。細工されたURIを送信するだけで、認証不要でヒープベースのバッファオーバーフローを引き起こせる。CVSS v4スコアは9.2で、リモートコード実行につながる恐れがある。

影響を受けるのは、NGINX Open Source 0.6.27〜1.30.0のほか、NGINX Plus、Ingress Controller、WAF製品群など広範囲に及ぶ。脆弱性は18年以上前から存在していたとされる。問題はHTTPリクエスト処理を担う ngx_http_rewrite_module にあり、特定の rewrite 設定で、正規表現キャプチャと「?」を含む置換文字列を組み合わせた場合に発生する。

攻撃者は単一のHTTPリクエストでワーカープロセスをクラッシュさせたり、任意コードを実行できる可能性があり、リバースプロキシやロードバランサとしてNGINXを利用する多数のサービスに影響する恐れがある。F5は修正版としてNGINX 1.31.0および1.30.1などを公開し、速やかなアップデートを呼びかけている。
https://t.co/UCdGPsYi3R

[うぇぶこ @WebEngrChild]

周囲を見てても目まぐるしく変わるトレンドとどんなに勉強しても網羅しきれない知識量に疲弊してエンジニアをやめる人がかなり多い。

でも少し落ち着いて考えてみると"今本当に自分が必要な知識"って以外と少なくて大切なことは選択と集中なだけ。

そして、今学ぶべき事=実務で携わっている課題を解決する手段です。

昇進・昇格においても、転職市場においても評価されるのは実務に沿った課題認識と解決に至るまでの思考のみです。

個人で学習した内容や資格取得は年収650万を超えたら評価割合は下がるし、年収7〜800万台以降になると実務経験が全てです。

本業フルコミットが最善だし一番コスパ良いんだよね。