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

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

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

たいした諸事情なわけでもないですが、だいぶ更新を空けてしまいましたので、ささやかなことからコツコツと書いていこうかと思います。 今回は、ALB(Application Load Balancer)の運用で得られた豆知識の記録です。 暖機運転の豆知識 申請の必要性 ALBはトラフィックが増加しても自動的に拡張して対応してくれますが、急激に増加すると拡張が間に合わずにキャパシティオーバーとなって、ALBがエラーを返してしまう可能性があります。そのため、事前にこのくらい跳ね上がりますので暖めて馴染ませておいてください。ってのが暖機運転（Pre-warming）です。 基本的には事前に申請して扱う仕組みですが、想定よりトラフィックが多くなり、エラーが多発し、数十分・数時間も解決しない場合もこの申請をすることがあります。この場合、ALBが自動拡張してくれない ＝ 何か他に問題がある 可能性が高いので

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

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

今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ

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

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

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

仕事力と技術力と不安に関する雑文 | YuheiNakasaka’s Diary を読んで、自分も勉強とは技術力とはなんぞやと考えてみたくなったのでポエムです。 詰まるところ人それぞれではあるものの、考えることは少なからず良い方向に向かう、そう願いたいものです。 勉強とは 世の中にある意見として、エンジニアは生涯勉強だとか、強々エンジニアになるための勉強だとか、色んなモノを見かけます。そういう勉強に対する意見ってたいていネガティブな印象の内容が多く、なんだか迷走しているなぁという感想を持つことが多いです。 良い子ちゃん視点では、学ぶこと、その全てには意義がある、と言いたいところですが、こと仕事においては無駄な学びもあるし、将来無駄になる学びもあります。また、自発的かどうかでその効果は天地の差があるので、他人に向かってこれくらいやるべきとか言うことの意味は薄く、突き詰めると自己責任の範囲の話

という感じで、特別に学歴が高いとか、小さい頃からコンピューターに触れてきたとかなくて、強いて言うなら３歳からゲーマーだったというくらいです。あとわざわざ北海道を出たのは、雪と寒いのが嫌いだからです。 振り返ってみると、入社からたった４ヶ月程度で退学を決心してて狂気ですね。決心した後は、まず社長に相談して、当時のバイト代だと生きていけないので、もう１つバイトしようと思います～って話したら、即断で社員になればいいじゃん。って流れになり、当時は役員とバイトだけだったため、めでたく正社員第一号になりました。 んで親に電話して、やりたいことが見つかったことと、今辞めれば後期の学費かからないよ！とか意味不明な説得したりして、なんとか了承を得ました。友達には全員に勿体ないと言われましたが、逆にこれが正着なんだと俄然やる気でました。 今現在、当時の生き残りは俺と社長だけですが、要所で即断即決できるってのは

前回の記事でイィ感じの燃え方してイラつきはしたけど、ちゃんと調べず適当に公開したのはマズかったし、どっちみちそれまで理解が浅かったのは事実で認識してたので、それはもういいんです。 それよりもなんで、昨今はこんなにクソコメが蔓延るようになったんやろって考えてみたくなりました。エンジニアに限らず、ジャンル問わず社会的な話でもあるのですが。 社会的な風潮 要は『叩く』という行為が流行を通り越して当然になってる風潮ですね。 エンジニア関連でも、昔から技術系掲示板では、そんなことも知らんのかい！とツンツンしながらも教えてあげる文化みたいなものはありましたが、そういう『限定的な場』に自分から踏み入れない限りは、エンジニア同士の交流の多くは所属や個人サイトが判明している人だったりして、誤りや改善点があれば、スマートに指摘して、素直に受け入れる、ような流れが多かったように思います。 SNSが流行りだしてか

全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来

AWS Aurora MySQLには、高性能を期待できる Parallel Query という機能があります。 実際、良いモノっぽいのですが、非常に情報が少ないので私めがいつものように掘り下げて、お役に立てればという徳を積む行為であります。 目次 Parallel Query とは リンク集 速度比較 費用の仕組み 設定による有効・無効 有効にできない条件 Parallel判定されるクエリ 結合クエリ innodb_buffer_pool_size との関係 その他 実践では Parallel Query とは 詳しくは下記リンクを見たほうがいいのですが、頑張って要約してみます。 通常のDB処理は、データを可能な限りメモリ上に置いておいて処理しようとしますが、オンメモリじゃないデータはストレージから取得する必要があり、データ取得後はDB本体における１スレッドがクエリ処理を行います。 Aur

ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在

C5が一歩抜けた強さの割に全部 ECU=10 な時点でアレですが、さらに6g系は該当なしです。で、費用的には c5/m5 の比率と c6g/m6g の比率は同じ 86% です。 第５世代では、C5 はメモリが少ない分、安くCPUが高速だったので強い選択肢でしたが、第６世代ではメモリが少ない分、安い。だけになるので、C系を選ぶメリットがだいぶ弱くなりそうです。 単純に、14％安くしてc6gにするって考えよりも、14％高くしてメモリ倍の方がよくねっていう。そういうパターンのほうが多いんじゃないかと、いうだけで全然絶対じゃないですけど。 考えようによっては、AutoscalingGroupに複数のインスタンスタイプを指定するとき、c6g, m6g, r6g と混ぜてもCPU使用率の格差がAZ以外で起きづらくなるだろうから、扱いやすくなると言えなくもない。 vs C5 あまりに差が付きすぎて、自分

『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。 そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。 職人芸とは 言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。 そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。 システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあ

最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ

十数年も同じ組織でエンジニアをやっていると、組織の様々な状態や方針を目の当たりにして過ごしていくことになります。 あくまで個人の感想ですよねんけども、どういう時にヤル気が出て、どういう時にため息をこらえてきたか、ようやく気づけたというか、そういうポエムの回でありんす。 ヤル気 = 自分が得意・好きなこと ではない まず最初にぶった切っておきたいのは、その時々に取り掛かっている仕事が、自分が得意だったり好きな作業だから、ヤル気が出るという話ではないです。 私の場合、名目上はインフラエンジニアではあるものの、最も楽しい作業は軽量言語を用いたコーディングであるし、最も時間をかけるであろう作業は初期段階での一般情報収集とドキュメント全読みだけど、重要なのはわかっててもあまり好きではないし、億劫なデータ整理だとしてもそれが必要な作業であれば別に嫌気が指すわけではない、など。 各々の作業に対して、必要