インプットのすゝめ | 外道父の匠
絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の
AWS VPC のネットワーク小話～Public/PrivateとIPv4/6～ | 外道父の匠
日々何気なくお世話になっている VPC 含むネットワークは、ちゃんと理解しようとすると思ったより多い情報量と、それに対するパターンの経験が必要になります。 私自身、正直ネットワークのお話は好きじゃないのですが、現行の事情を踏まえてこの辺の基本と雑学を振り返っておくと、技術力のベースが整ってよろしいのではと思って整理することにしました。 はじめに 新年度なので、学習教材シリーズです。今回はネットワーク周りで、基礎に味付けするような内容です。もしかしたらお嫌いなジャンルでしょうか、でも少しだけやりましょうそうしましょう。 関連情報としては、このあたり。 公式 ENOG81: AWSのIPv6とPublic IPv4のおはなし – Speaker Deck Amazon VPC とは? – Amazon Virtual Private Cloud 外道父の匠 AWS VPCルーティングの基本から
AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
AWS Lambda IPv6 と APIエンドポイントと NAT G/W | 外道父の匠
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 内容的に、確認したいことはすぐ成功して終わるだろうと
AWSの削減対象なPublicIPの調査 | 外道父の匠
各アドレスが何に割り当てられているかのリストも見れるので、基本的には全容を把握することが可能です。 ただし注意点として、閲覧した現時点での情報である、ということです。 EC2 の PublicIP を課金目線で数える PublicIP の有料化は１時間単位のため、Insights で見て現在の情報で計算しても、AutoscalingGroup のリソース量変動によって、少し実情と離れた結果になりそうなので、工夫して数えます。 CloudWatch 管理画面で、【すべてのメトリクス】→【Auto Scaling】→【グループメトリクス】に移動し、＜GroupDesiredCapacity＞を検索に追加します。 出てきた AutoscalingGroup で Public Subnet に属するものに全てチェックを入れれば、まずは現在の実台数を表示できるので、その数値を全て足しておきます。そし
RDS Auroraのネットワーク速度上限 | 外道父の匠
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を軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ！ コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew
AWS RDS/AuroraのDDL運用を最適化する | 外道父の匠
AWS re:Invent 2022 にて RDS の Blue/Green が発表されたことを受けて、この辺の具体的な運用をどのように改善できるのか考えていきます。 たいした内容ではないですが、丁寧に最適化して慣れれば、それなりに強い効果を発揮できそうな感じはあります。 ALTER TABLE の辛み まず復習からですが、RDS に Blue/Green が実装されるほど辛い運用はなんだったかというと、重い ALTER TABLE にあります。 ALTER には色々あるのでアレですが大雑把に言うと、容量や行数が大きいテーブルに対して実行すると、数時間単位～の処理時間がかかることが多く、しかもパッと見で進捗を把握できないという問題を抱えていました。それに対して色んな対策を取っていたと思います。例えば…… Handler_write SHOW GLOBAL STATUS LIKE ‘Hand
AWS Graviton2 新CPUの性能検証 | 外道父の匠
C5が一歩抜けた強さの割に全部 ECU=10 な時点でアレですが、さらに6g系は該当なしです。で、費用的には c5/m5 の比率と c6g/m6g の比率は同じ 86% です。 第５世代では、C5 はメモリが少ない分、安くCPUが高速だったので強い選択肢でしたが、第６世代ではメモリが少ない分、安い。だけになるので、C系を選ぶメリットがだいぶ弱くなりそうです。 単純に、14％安くしてc6gにするって考えよりも、14％高くしてメモリ倍の方がよくねっていう。そういうパターンのほうが多いんじゃないかと、いうだけで全然絶対じゃないですけど。 考えようによっては、AutoscalingGroupに複数のインスタンスタイプを指定するとき、c6g, m6g, r6g と混ぜてもCPU使用率の格差がAZ以外で起きづらくなるだろうから、扱いやすくなると言えなくもない。 vs C5 あまりに差が付きすぎて、自分
負荷試験＃サーバーアーキテクチャ事例 | 外道父の匠
図を書いて気分転換したくなったので、アーキテクチャについて軽く触れます。 細かくは省いて、負荷試験の大雑把なサーバー構成にはどのような選択肢があるのか、の事例を出していきます。 登場人物 超ざっくり分けると３つに分類されます。 基本AWS内での利用を想定していますが、User と Server は別にどこの環境でも大丈夫なようにしています。Client は ECS Fargate で使い捨て。 私の場合、実際にどのような構成で試験できるようにしたのか、を紹介していきますが、これだけ見ると至って普通な内容かもしれません。 １：１ ダイレクト型 まずは最もシンプルな構成で、主に動作テスト用です。 これだと普通にLocustを動かすのと変わらない構成です。実行命令と負荷リクエストを出すサーバーが同じで、任意の１ホストへリクエストを送信します。 Server は Host を指定するだけなので、経
負荷試験＃性能基準単位 | 外道父の匠
１つのリクエスト処理が完了するまでは大雑把に書くと User → Request → Web → App ↔ DB/KVS User ← Response ← Web ← と一連の流れがあり、当たり前ですけど、AppサーバーのCPUが稼働するのはAppの部分の処理だけになります。なので、1 : 1 で負荷をかけても、ネットワーク等のレイテンシによりAppをフル稼働させることが微妙にできなかったりします。 となると、1vCPU = 100% としての計測値を確実に採取したいならば、vCPU数より多いClient数が必要になります。そして、Client数に対してWorker数が足りないと、接続待機またはエラーが発生するので、Worker数もまたvCPU数より多い方が確実になります。 概ね1vCPU=100%での計測値を採取できれば良い、という考えでもある程度はイケるかもですが、ただ漠然と行う負
負荷試験＃実行条件と傾向観察 | 外道父の匠
負荷試験シリーズ、今回は実行時の条件と結果の読み取りについて考えていきます。 どのようなな調整で負荷試験を進めていけば、より効率的に正確な成果を得られるのか。これはただのパワーゲームではありません。 誤った考え方 アプリケーションが多様ゆえに、負荷試験にも完全な正解はないかもしれませんが、限りなく正着といえる手法はあります。 負荷試験を始めましょう、となった時にヤラカシがちなのが、いきなり本番想定のサーバー量で試験を始めることです。このサービスの想定DAUがいくらで、ピークタイムのRPSがいくらになりそうだから、サーバーはこのくらいだろう。と用意してそれに負荷をかけ、大丈夫だの足りないだのやりだすことの、なんと意味の薄いことか。 もしそれがオンプレミスならありえます。なぜなら、サービスが完成するだいぶ前には物理サーバーの準備ができている必要があり、そこから増減を考える意味がないからです。今
負荷試験＃基本リンク集 | 外道父の匠
前の記事は実は前フリで、最近、負荷試験について深く潜り込んだので、自分なりに考えたことを細かく分けて書いていこうと思います。負荷試験シリーズのはじまり:-) 後半はほとんど自分で考えて色々実装しましたが、序盤は先人の知恵をかき集めてイィトコ取りしたので、メモっておいたリンク集を置いておきます。 はじめに 負荷試験ってツールを選んで大量リクエストを発生させるんでしょ。ってイメージがあるかもですが、より効率的により正確にって仕上げていくと、独自に実装したい仕組みが結構でてきます。 アプリケーションは当然モノによって仕組みや構成は異なるし、プロトコルが異なる場合もあります。千差万別は言いすぎかもだけど試験には色んな選択や工夫があり、これが正解っていう単純なものではないのは間違いないです。 とはいえ、シンプルな実行と結果でも、複雑な取り組みをしたとしても、求められる成果に対して十分で正しい結果を示
SRE四大行 | 外道父の匠
元々なんでも屋ってたけど、我が部署名もSREになったし、インフラエンジニアって書くと『IT』警察が寄ってくるからSREでいきましょう。短いのはイィ。 SREがやることは書籍『O’Reilly Japan – サイトリライアビリティワークブック』がほぼ語っていますが、もうちょっと噛み砕いて自分的にはこの四大行を軸に活動すれば、いっぱしのSREになれんじゃねっていう戯れであります。 SREのお仕事を大雑把に表現すると、サービス開発者が作成したアプリケーションを、動かす環境を用意し、安全・効率的に動かし続けることだと思っています。 IT業界の事情変化につれて、SREの重要性は高まる傾向にあり、それに伴いSREとして活動を希望する人材も増えたような、そうでもないような。気がするけど、SREとして食ってく気ならこれら四大行が基本であり奥義になるよって話です。 『構築』 アプリケーションを動かすための
AWS ECS Fargate のCPU性能と特徴 | 外道父の匠
ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在
AWS ECS Exec を使ってみたTips | 外道父の匠
ここ１ヶ月半くらい、ちょっとした独自システムを創っていたのですが、そこで編み出したテクニックを紹介してみます。 要はECS Execを使い込んだよってだけなんですが、こういうオモチャを使ったオモチャを作らせたら一級品の自負、ある。 ECS Exec の概要 基本的なところは他に任せたいのでリンクだけ貼っておきます。 New – Amazon ECS Exec による AWS Fargate, Amazon EC2 上のコンテナへのアクセス | Amazon Web Services ブログ [アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました | DevelopersIO デバッグに Amazon ECS Exec を使用する – Amazon ECS 外からコマンドを実行できる旨味 ECSっていっても自分の中では Fargate の話にな
AWS API Gateway HTTPのAuthorizer設定 | 外道父の匠
あけおめ☆ 年末年始を長期休暇にしたせいで、起ち上がりが悪い。エンジニアたるもの、そんな時はコーディングだ。Pythonでモチベーションを取り戻すんだ！ その気持ちだけでクールなシステムを考案・構築してしまったので、書いていきたいんだけど、物事には順序がある。まずは HTTP API Gateway に認証をつけるとこから、ブログの暖機運転なのだ。 おさらいと公式 前に、API Gateway の基本的な部分は↓↓に書きました。 AWS API Gateway v2 の Terraform構成 | 外道父の匠 AWS API Gateway v2 HTTPの基礎練習 | 外道父の匠 認証の仕組みがなかったので、まぁこんなこともできるよねって意味で、オレオレ認証も書いたんだけど、その後すぐに公式で対応されたわけです。 API Gateway HTTP API が Lambda および IAM
Aurora運用Tips IOPS編 | 外道父の匠
久々にAuroraについて、小ネタ系で書いてみるテスト。 主にストレージIOPSにまつわるTipsで、光り輝くモノは別にないですけど、基本が大事ということで。 ストレージIOPSのグラフ生成 データベースの運用において、監視データであるメトリクスを色々収集するのは基本ですが、その中でも最重要に位置する項目である ストレージのIOPS についてです。 まず、Auroraのストレージ構成は共有型であり、IOPSメトリクスはホスト毎ではなくクラスタ毎のデータとして記録されています。 参考ページ Aurora ストレージエンジンのご紹介 Amazon Aurora DB クラスターメトリクスのモニタリング RDS Aurora の管理画面でモニタリングを見ると、グラフ名が [請求済み] ボリューム読み取り IOPS (カウント) [請求済み] ボリューム書き込み IOPS (カウント) となってい
RDSで接続数とメモリ消費量の調整事例 | 外道父の匠
RDS Auroraを使っているところで、OSの空きメモリが少なくなったアラートが出たので、それについて細かく考察したら、それなりの量になったのでまとめた感じです。 別にAuroraじゃなくRDS MySQLでも、MySQL Serverでも同じ話なのですが、クラウドならではの側面もあるなということでタイトルはRDSにしております。 RDSのメトリクス監視 RDSはブラックボックスとはいえ、必要なメトリクスはだいたい揃っているので、CloudWatch を見たり……APIで取得してどっかに送りつけたりして利用します。 なので、まずは接続数とメモリについて復習です。 SHOW STATUS 的には Threads_connected です。 CloudWatch Metrics 的には、DBInstanceIdentifier → DatabaseConnections です。 見た感じ、ど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
