Autoscaling については過去に何度か書いているのですが、今回は ECS Fargate について少し掘り下げつつ整理してみたいと思います。 仕組みとしては難しくはなく、わりと雑な理解度でも動くっちゃ動くとはいえ、リソースとしての重要度は高い箇所であり、正しく理解するとより関連箇所の最適化が見込めるところでもあります。 概要 ECS は on EC2 で動かすと、インスタンスとタスクの二段階での Autoscaling になるところが、Fargate だとタスクのみで考えられる簡素さが強みです。 ECS Service のタスク群に対して、特定の条件（主に平均CPU使用率）を満たした時にタスク数を自動的に増減することで、負荷対策とコスト削減という目的を達成しつつ、運用者が基本は放置できることになります。 ただ、それだけの理解では浅すぎるので、増減における詳細やリスクなどについて把握

回数上限 便利な代わりといってはアレですが、検索回数が１ヶ月あたり 10000 回に制限されています。 Resource Explorer のクォータ – AWS Resource Explorer 定期処理で実行した場合、 １分に１回なら月に 44640 回、 ５分に１回なら月に 8928 回、 60分に１回なら月に 744 回、 となります。仮に５分毎だとしても、１種類の処理で９割を使っちゃうので、複数種類の処理で使うことは難しくなってしまいます。 この対応策として最初の思い浮かぶのは、当然クォータから上限引き上げの申請をすることですが、現在はこの項目の上限増加は対応していません、という返答が返ってきます。 もし上限に達してしまった場合は、その月はもう検索ができないので、来月を待たなくてはいけなくなります。自分の場合は、１日の 10時台 にリセットされました。 こういうタイプの詰み方っ

ECS Fargate の ARM64 版は長らくスポットが使えませんでしたが、ようやくやってきました。 利用するにあたって、いくつかポイントと注意点があるので、ザックリと把握しつつ自分用にどう構成するかを考えていく感じになると思います。 はじめに リリースや価格についてはこちらにまとまっています。 [アップデート] Fargate Spot で AWS Graviton ベースのコンピューティングがサポートされました | DevelopersIO 東京だとオンデマンドに比べて 62% OFF くらいです。前は Blue/Green の場合にスポットを利用できませんでしたが、今は解消されドキュメントからもその記述は消えています。 落ちやすさはまだわかりませんが、EC2 の例だと X86 より ARM64 の方が安定している雰囲気があるので、Fargate においても速い・安い・安定を期待で

最近、システム開発はこうあるべきだよなって考えていたのと、他所のエンジニアリング文化についての記事を見たことから、自分にとっての今の理想と現実の間について整理して吐き出しておきたくなりました。 所詮理想ではあるものの、自身の環境におけるベストに近づけようとする思考や、ベストに程遠い状況を認識する、ということには意味があるのではないかと思う次第です。 はじめに 自分は100％WEB系出身ですが、全く異なる文化である SIer 方面のお話を読むのはわりと好きで、これらは興味深く読ませてもらいました。 誰も教えてくれないSIの本質、SIerの世界観 日本のSIerの技術力の低さの要因から考えるアメリカソフトウェアの強さ – きしだのHatena プログラミングが設計作業であるという話 – きしだのHatena ソフトウェアの「詳細設計書」とはなんなのか – きしだのHatena だいたい SIe

コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し

自身の過去の成長過程と現在の環境を思い浮かべたときに、得やすいもの得づらいものの違いを強く感じ、良好な成長のために一考してみた次第です。 といっても既にある Tweet のセルフまとめに、思い出と昔話なポエムを追加したようなチラ裏回です。 時代の変遷によるステータス変化 要約すると、現代は技術力の向上に必要な環境と既定路線があって向上速度が早いのに対し、昔（2010年以前とか）は頭を悩ませまくって乗り越えるべき壁が大量にあったおかげで解決力は相当鍛えられたよねってところ。 個人的には誰であれ、今！自分が！解決しないと！詰んでしまう!! てかもう詰んでるだろコレ!!!! って状況でひたすら悩んでから、寝て起きたら解決したよぉ！みたいのを体験してほしいし、一度は死の淵まで行ってこいって思っている — 外道父 | Noko (@GedowFather) July 17, 2024 これについて、

公式の説明による大きな変化点は、 Graviton 2 → 3 の時は、性能25％UP で費用6％UP、Network/EBS 帯域幅が向上、 Graviton 3 → 4 では、性能30%UP で費用10％UP、最大スペックが３倍、 に加えて、細かいところでも色々少しずつ向上しているという感じです。 特にスペック３倍は、データベース用途におけるスケールアップが強力で、一時的な緊急負荷対策としても強いし、クラスタデータを３分割するくらいなら１クラスタで分割なしで貫けばいいじゃない、など安定と選択の幅が広がるのは間違いないでしょう。 ベンチマーク それでは、疑り深い外道父さんによる、いつもの Phoronix による検証です。 今回は R系 という点と、あまり古いのと混ぜると共通成功テスト数が減ってしまうことから、R6g, R7g, R8g での比較としています。C7i 以前なども知りたけれ

数値上はこうなるものの、意図的な短期的メンテナンスや、意図しない障害でも１回あたりの期間が短ければ、その期間に積まれるはずだった売上は、その復帰後に売り上がる場合も多いでしょう。その辺りは、ユーザーの信頼を損なわない方法や運用を心がけることで、十分に埋められる可能性を含む性質です。 しかしこれが、あまりに高頻度であったり長期間になると、その復帰後に停止期間分を含めた売り上げにならず、そのまま機会損失となる可能性が高まります。いわゆるユーザー離れというやつです。その損失だけで済めばまだマシで、普通に考えればその後に想定していた売上も減少し続け、元に戻すには相応の時間と労力を伴うでしょうから、数値以上の痛手となるはずです。 こう考えていくと、運用関係者が健全であれば、無理に100％の可用性を目指さず少なくとも合計99％以上となる停止猶予を持たせた運用とし、数日を跨ぐような連続した長期間の停止だ

まいど AWS の犬が、少々 Azure に触れてみましたので、絵は描かずに基礎知識の整理と共有だけしていきたいと思います。 全然ド素人な状態なので、なにかしら間違ってたり不足していると思われますが、同じようにイチから調べる人の足がかりにでもなれば、くらいの質感で進めていきます。 はじめに 今のところ少々用事があっただけなので、これから Azure を掘り下げるぞとか、Azure の犬になるぞ、とかは考えていなく一発ネタで終わる可能性が高いです。雑なメモをブログに起こして、いったんの区切りとする個人的な清書のため、詳しくはちゃんとリンク先のドキュメントなどを読んでくださいませ。 さて、AWS に似たパブリッククラウドはいくつもあり、Azure もその１つです。公式ドキュメントに何箇所も AWS との比較が出てくるくらいには、Azure も AWS を意識しています。 例）AWS サービスと

幼い頃から色々子どもに教えてきて、今は中学生の１年間が経過したところで、学習環境について整理してみます。 特に前記事で書いた インプットのすゝめ | 外道父の匠 に繋がるところで、学習の軸となるインプット・ソースについては誰しも一考の余地アリなのではと思っています。 学習の目的 これは家庭によって異なるところなので、目標地点はどこでもいいとしても、少なくとも何もやらないとか、漠然とヤレって指示するよりは目的や目標があったほうが親子ともに良いと思います。 小学生なら通知表の『とてもよい』が 2/3 以上とか、中学受験に合格するとか。受験については過去に振り返りをしています。 都内における中学受験の感想戦 | 外道父の匠 中学受験における検討項目 | 外道父の匠 中学生なら通知表を良くしたり、期末テストや全国テストでより上位を狙うとか、高校受験があるならその合格へ、と。 学習において重要なのは

絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の

リクエストヘッダに『Accept-Encoding: gzip』を含む場合、クライアントが「gzip圧縮して返しても大丈夫よ」って言ってるので、サーバー側はレスポンスを返す際に条件を満たしていれば、レスポンス・ボディ部分を圧縮した上で、レスポンス・ヘッダに『Content-Encoding: gzip』を付与して「gzipで圧縮しておいたよ」と返します。 WEBサーバーに限らず、CloudFront といった CDN も同等の機能を持っていて、圧縮メリットがあると判断した場合は有効にしておくとよいでしょう。 圧縮ファイルの供給 – Amazon CloudFront 圧縮の目的 ここはエンジニアとしての話というても、自宅パソコンでも何かしら圧縮機能は使っているでしょうから、説明は不要でしょうが…… メインは容量の縮小、次いで複数データを１ファイルにまとめる、ってところで今回は容量縮小を”手

日々何気なくお世話になっている VPC 含むネットワークは、ちゃんと理解しようとすると思ったより多い情報量と、それに対するパターンの経験が必要になります。 私自身、正直ネットワークのお話は好きじゃないのですが、現行の事情を踏まえてこの辺の基本と雑学を振り返っておくと、技術力のベースが整ってよろしいのではと思って整理することにしました。 はじめに 新年度なので、学習教材シリーズです。今回はネットワーク周りで、基礎に味付けするような内容です。もしかしたらお嫌いなジャンルでしょうか、でも少しだけやりましょうそうしましょう。 関連情報としては、このあたり。 公式 ENOG81: AWSのIPv6とPublic IPv4のおはなし – Speaker Deck Amazon VPC とは? – Amazon Virtual Private Cloud 外道父の匠 AWS VPCルーティングの基本から

米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ

今のところ、AWS IPv6化や PublicIP 外しはボチボチやったり、いったんやらない判断したり色々です。 そんな中で、考察し直した部分や、新しく考察した事例などが出てきましたので、整理していきます。 はじめに 既に AWS IPv6 についてはいくつか書きましたので、その続編ということで。 AWSのPublic IPv4構成をIPv6に切り替える | 外道父の匠 AWSの削減対象なPublicIPの調査 | 外道父の匠 AWS Lambda IPv6 と APIエンドポイントと NAT G/W | 外道父の匠 AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠 当初は PublicIPv4 有料化対策のつもりで書き始めたシリーズであり、それ自体は別に間違いじゃないのですが、IPv6 化をすれば即・万事メデタシになるというわけでもない、ということで色々学びつつ判断して

これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr

Terraform を色々見直している中で、CodePipeline の経過を知らせる仕組みに、CodeStar Notifications を使っている箇所がありました。 今回はそれを EventBridge を使う形式に変更した、というか旧式に戻した、地味なあけおめ回です。 変更理由 Terraform やら機能構成そのものを練り直している際に、もっと簡略化とか最適化できないか考える中で、CodeStar Notifications を使ってチャットに通知している箇所がありました。 CodeStar 本体は使っておらず、Notifications だけ使っている状態で、リソース構成も正しいとはいえ複雑気味に感じたので、なんとかならないかなーと調べたところ、そもそも 2024年7月31日 でサポートが終了する旨が、ドキュメントやコンソールに表示されていました。 2024 年 7 月 31

昔は社内で自分主催の勉強会をやることがあって、それを『外道塾』と称していました。 最近手掛けた、丸っとまとまりのよい技術話ができたので、忘年会をかねて会社＆オンラインで開催しまして、それのただの感想となります。 題材 ひょんなことから、最近の色々を最適化しつつ再構成したものがありまして、ECS を軸とした全てって感じの内容です。ECS が EKS に入れ替わっても大丈夫、くらいの情報構成のつもり。 Docker , Git , ECS , Code系 , Rails あたりの、開発やインフラ設計からデプロイまでを、イィ感じに分解しつつ、社内用に教科書コンテンツを作って、ぶっつけ本番で昼食含めて３時間半ほど話しました。 とはいえ昔から勉強会そのものの効果はあまり期待していないので、どっちかっつーと書いた教科書をあとからいつでも誰でも見れるように残したところがメインの目的ですが、 参加者には、

自分はそんなに情報収集に熱心な方ではないとはいえ、流れていく技術情報の中で関係しそうなものは目を通すし、昔から好きな組織・エンジニアのブログ・チェックくらいは継続しています。 古のエンジニアは時間経過や転職を機にパッタリ途絶えたりして減っていくも、稀に若手や新人ぽい人のアウトプットが目につくと、時代事情も相まってとても応援する気になるし、こちらも負けじと頑張る気になるってモンです。 混沌から王道へ 今の時代に、駆け出しや初級者としてアウトプットを始めるのって難しいんじゃないかと思うことがあります。 昔はハードからソフトまで貧弱だったり、色んなOSSや選択肢があって、これぞ正攻法という解がなかった混沌だったからこそ、多角的な切り口のアウトプットをしやすかったように思います。 今はクラウドの出現や、ソフト・ミドルウェアの成熟により、ある程度の正攻法が見えやすくなった上に、細かい知識や調整が不要

以前、AWSコスト削減とリソース管理 | 外道父の匠 のEBSの項では、そもそも不要なEBS・スナップショットの判断をしましょうってのと、gp3 にして安く高性能にしましょうと書きました。 今回はそのうちの gp3化 についての外伝ということで、さらりとまとめておきます。 費用差 gp2 が $0.12/GB 月、gp3 が $0.096/GB 月 なので、gp2 から gp3 に変更すると 20％ の費用削減になります。 ハイパフォーマンスブロックストレージの料金 – Amazon EBS の料金 性能に関しては、gp3 の 125 MiB/s 3000 IOPS が判断基準となる数値で、もし gp2 の時に、それ以上の性能を使い込むタイミングがある場合、gp3 にしただけで安く速くなったと安易に喜ぶことはできなくなります。 よほど読み書きが盛んなボリュームの場合は、メトリクスをチェック