絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・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 にしただけで安く速くなったと安易に喜ぶことはできなくなります。 よほど読み書きが盛んなボリュームの場合は、メトリクスをチェック

何度か外から AWS の Aurora MySQL へサービス移行をして知見が溜まっていたので、吐き出しておきます。DBA 専門的な人から見たら別におもろくない内容だと思いますので、初中級者の学習用教材です。 最初は全体の流れを全て書こうとしましたが、全く同じ流れでやることはないだろうと思い、部分ごとにこういうことを検討すればえぇんちゃうんくらいの Tips にしてみました。 目次 そこまで長くないですが Tips なので目次を置いておきます。 データ転送の方法 当日にバックアップ／リストア 事前にレプリケーションする 通常レプリケーション 直にグローバルアドレスへ接続 VPN経由で接続 レプリケーション開始 DMS経由レプリケーション リンク集 メリット 大まかな流れ 非対応 DDL binlog_format バックアップの方法 mysqldump mysqldump 独自並列 mys

AWS Lambda in VPC から、IPv6 で Egress-only internet gateway を通って外に出ていけるようになりました。 それに関連して、APIエンドポイントと NAT G/W を絡めて確認したことをまとめておきます。よくわからないタイトルになりましたが、雑学用の材料ということで:-) リリース 公式情報はこちら。 Announcing AWS Lambda’s support for Internet Protocol Version 6 (IPv6) for outbound connections in VPC 英語版はLambda の Dual-stack が Yes に AWS services that support IPv6 – Amazon Virtual Private Cloud 内容的に、確認したいことはすぐ成功して終わるだろうと

費用は C7g の 123％、C6i の 105％ といったところで上昇。細かいところでは色んな上限値が上がったりしているようです。 CPU情報はこんな感じ。Q1’2023年モノです。 インテル® Xeon® Platinum 8480C プロセッサー $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 143 model name : Intel(R) Xeon(R) Platinum 8488C stepping : 8 microcode : 0x2b000461 cpu MHz : 3746.354 cache size : 107520 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid :

２年半近く前に書いた AWS ECS Fargate のCPU性能と特徴 | 外道父の匠 の続編になります。 そんなに楽しくはないけど、知っておいて損はない、くらいの調査と考察になります:-) 前口上 ちょうど１年前に FARGATE のリソース天井が上がりました。今回は、ほぼそれを区切りにした結果になっていると思います。 AWS Fargate でコンピューティングとメモリのリソース構成が 4 倍に増加 vCPU 条件と Availability Zone を変え、３タスクずつ起動し、出現したCPUモデルをメモっていきました。ついでに軽量ベンチマークとして前回同様 OpenSSL speed をカマしておきました。 関係ないけどコンテナイメージは amazonlinux:2 です。では結果をどうぞ。 出現CPUモデル CPUアーキテクチャを選べるので、それぞれについて。 ECS Farg

Terraform のコーディングにおいて、似た構成の複製をどのように表現するかは結構重要な課題です。放っておくと汚いコピペだらけになっていくからです。 色々な目的とやり方があると思いますので、その表現を実現するためのパーツにでもなればと思い、学習用教材的に書いてみるやつでございます。 目次 説明はそんなに多くないですが、コードのせいで縦長になったので目次を置いておきます。Terraform バージョンは v1.5.7 で動作確認しています。 単体の複製 count for_each セットの複製 module count + module 条件分岐 三項演算子 入れ子 ループ構造 for 複製の方法 階層構造 Pythonの入れ子ループ Terraform の入れ子ループ 続・階層構造 単体の複製 あるリソースに対して、単体の場合は count や for_each を使うことで、lis

ある意味、表現だらけの昨今において 『表現』というものは、”呪い”だ。 – orangestar2 の捉え方は面白く、改めてエンジニアにおける『表現』＝『アウトプット』について考えたくなりました。 遥か昔に書いた エンジニアがアウトプットすべき理由 | 外道父の匠 は、技術面向上の役に立つよ、という話でしたが、今回は私自身の精神的な面の振り返りになります。ITエンジニア全体に対してとかじゃないので、そこんとこよろしくポエム。 『表現』の意義 【個の責任】において、公のインターネットという場でサービスを提供したりエンジニアリングについて発することを『表現』する、ということにします。閉じたイントラネットや、複数人による成果は、責任の度合いの性質が全く異なるので、ここではあえて定義を絞っています。 結論から言うと『表現』は突き詰めて言えば【自己満足】でしかありません。 発する内容の品質や精度が向

各アドレスが何に割り当てられているかのリストも見れるので、基本的には全容を把握することが可能です。 ただし注意点として、閲覧した現時点での情報である、ということです。 EC2 の PublicIP を課金目線で数える PublicIP の有料化は１時間単位のため、Insights で見て現在の情報で計算しても、AutoscalingGroup のリソース量変動によって、少し実情と離れた結果になりそうなので、工夫して数えます。 CloudWatch 管理画面で、【すべてのメトリクス】→【Auto Scaling】→【グループメトリクス】に移動し、＜GroupDesiredCapacity＞を検索に追加します。 出てきた AutoscalingGroup で Public Subnet に属するものに全てチェックを入れれば、まずは現在の実台数を表示できるので、その数値を全て足しておきます。そし

AWS の IPv6化について調査は済んだけど、書き始めるのに非常にドンヨリしております。図を書いて少しでも楽しくいきましょそうしましょ。 皆様も読んだらドンヨリするかもしれませんが、できるだけ丁寧に書いてみますので、PublicIP 有料化に抗いたい人は頑張って追ってみてください:-) 目次 また長いです。でもひきかえさないほうがいいかもしれない。 はじめに 前提知識 目的 IPv6 の設計 従来のプライベート IPv4 IPv6 の割り当て Gateway と Routing VPC SecurityGroup Network ACL Subnet Egress Only G/W NAT64 RouteTable Public Private インスタンスで動作確認 IPv6 アドレスの確認 IPv6用の設定 疎通確認 IPv6リソースの配置 既存リソースの入れ替え アプリケーションの

r6g より r6i の方が若干高いですが、その分、性能が若干良いっぽいのと、スペック的にもネットワークGbps が高いので、こちらを検証対象としています。 果たして『最大 12.5 Gbps』という数値はどこまで本当なのか、【最大】という魔法の言葉・ベストエフォートで軽くあしらわれるのか、簡易的ではありますが検証していきましょう。 クライアントとDBデータの準備 まずは Aurora を起動します。バージョンは最新の【Aurora MySQL 3.04.0 compatible with MySQL 8.0.28】で、インスタンスタイプは【db.r6i.large】です。 次にクライアントをスポットで起動します。イメージは【Amazon Linux 2】でインスタンスタイプは【c6i.large】です。とりあえず mysql コマンドだけ入れます。 sudo yum -y install

クラウド使いなエンジニアの皆様、猛暑と円安の中いかがお過ごしですか。上層部からインフラコスト削減を突きつけられてはおりませんでしょうか。 今回はおそらく初めてコスト削減についてAWSを軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ！ コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew