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
Kubernetes、やめました | 外道父の匠
最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ
これからはじめるインフラエンジニア 発表資料 | 外道父の匠
新卒採用のイベントで『知的ヘンタイ六番勝負』というのをやっていまして、その『第三戦 大規模インフラ・解析勉強会』にてインフラについて話してよ、と人事オファーをいただきまして発表した次第でございます。 エンジニア志望とはいえ、不特定多数の人間に対してインフラの話と一口で言われても、誰が何をどれくらい理解してるのかわからないので厳しい案件ではありましたが、せっかく来ていただくので真面目に張り切った結果、質疑応答含めて１時間弱に渡る発表＋風邪でノドが潰れた資料がこちらになります。 補足 新卒の方々に向けて これまで新卒の人に関わる機会がなく、インフラについてどの程度理解があるのか全くの不明でしたが、思っていたより勉強しているなという感触と、良いエンジニアになれそうな匂いを発している野郎も結構多かったな、という印象でした。 資料でも触れてますが、WEBエンジニアを目指した時に、何を武器に何エンジニ
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
Fluentdの所感 その１ | 外道父の匠
Agent ログの量やFluentd＆CPUの性能を考えると、負荷的には１サーバ１Agentで十分足りるので、ステータス検知などの監視だけしっかりしておけばOKと考えます。なので例えばWEBサーバに普通に１Agent入れてそれが数百・数千台になることを想定します。 Collector 複数台用意し、Agentからroundrobinで送信することで均一化します。Collectorダウン時や復旧時は、ログのロスト無しにすみやかにroundrobinから外れたり復活することを確認済みです。台数が増えすぎた時の懸念点は、HDFSに対する１ファイルへのAPPEND数が増えることですが、ここまでの試験を見る限りはおそらくかなりの数まで大丈夫ですし、仮にHDFSへの書き込みが問題になる場合はAgent -> Collectorの選択条件や、書き込みファイルパスで工夫すれば大丈夫です。 とはいえ、APP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
