AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ
AWSコスト削減とリソース管理 | 外道父の匠
クラウド使いなエンジニアの皆様、猛暑と円安の中いかがお過ごしですか。上層部からインフラコスト削減を突きつけられてはおりませんでしょうか。 今回はおそらく初めてコスト削減についてAWSを軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ！ コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew
AWS ALB+ACMの意外な落とし穴 | 外道父の匠
全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来
Kubernetes、はじめました | 外道父の匠
冷やし中華の季節になりましたので、Kubernetesをはじめました。もとい、はじめてしまいました。 前回のECSシリーズに比べると、だいぶ世界が広いシステムであり、１つのシリーズとしてまとめるとか、全部終わってから書き始めるとか、どうにもできそうになかったので少しずつ進めることにします。今回は、雑感とリンク集のみで、助走というか覚悟を決める回という位置づけになりやす。 これまでの率直な感想 触り始める前の僕 Kubernetesの情報がやけに目につくけど、なんか煽り感が強くて気に食わん…… ていうかクラウド界の「Linux」ってなんやねん俺は騙されんぞ！なんかイケ好かないシステムくさいな！！ 数日間、情報収集した僕 このクラウド全盛期に、なんでいまさらクラウドの中にこんなプラットフォームを構築せなアカンねん、オンプレでやれ。 納得いく構成と構築まで頑張った僕 なんだかんだで手足のように動
ミドルウェア性能検証の手引き | 外道父の匠
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
AWSの複雑な仕組みをTerraform化で紐解く事例 | 外道父の匠
インフラエンジニアも、そうでないエンジニアも、程度の差こそあれAWS（パブリッククラウド）の知識は欠かせないものになりつつあります。しかしながら、食わず嫌いだけならまだしも、AWSにそこそこ取り組み続けているのに、しばしば嫌気がさすことすらあるのは、AWSの複雑さが原因の１つであるといっていいでしょう。 今回は、そんな複雑な仕組みの一つを、Terraform用にコード化することでココロのスキマ、お埋めします。 Infrastructure as Code の過程 Infrastructure as Code によって、手動管理をやめて自動化することのメリットは言うまでもないですが、今回は自動化する過程にこそ非常に大きなメリットがある、という視点にスポットを当てていきます。 AWSは多機能で便利であるがゆえに、複雑です。そして、複雑であるがゆえに、お客さんに簡単に扱ってもらえるよう、操作が簡
ドリコムを退職しました……弟子が | 外道父の匠
世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 本人には「退職エントリ書くね！」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4～5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン
systemd時代に困らないためのlimits設定 | 外道父の匠
数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール／SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上
現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
書籍「たのしいインフラの歩き方」を執筆しました | 外道父の匠
エンジニアになってかれこれ14年目、そのうちの多くをインフラエンジニアとして過ごしてきました。ドリコムが弱小ベンチャーの時代から始まり、上場を経て今に至るわけですが…… そんな私の経験を凝縮したような書籍 『たのしいインフラの歩き方』 を執筆しましたことを、ご報告させていただきます！ 本の概要 タイトルどおり、インフラ周りの歩き方について記したものであるため、これを読めば環境を構築できるとか、深い技術や仕組みを理解できる、というようなザ・技術書といった類の内容ではありません。 では、ここでいう歩き方とはなんぞや？といいますと、起業したての小企業から、数百人規模の大企業に至るまでに、どのような技術的要望があり、どのように解決していくのか、という時間軸や規模感に沿ったインフラのエンジニアリングや、その心構え、ということになります。 対象読者としては、大きくは初～中級者のエンジニアとなっています
AWSスポットインスタンスの真髄 発表資料 | 外道父の匠
6/17(水)にオプト社で開催された、愛の貧乏大作戦！ケチケチビッグデータ節約術（市ヶ谷Geek★Night #2） にて発表してきましたので、その資料を公開します。 久々の登壇で張り切りすぎまして、資料が長くなってどう考えても時間が足りなかったので最後の工夫うんぬんはカットしちゃったのですが、この資料はノーカット版にしましたので会場にきていただけた方も再度オマケを楽しんでいただければと思います。 スポットを使おう AWSの中の人曰く、スポットはまだまだ多くは使われていない印象で、もっと使ってほしいとのことでした。なので、この内容を参考にしていただいて、さらにアグレッシブな攻めのアーキテクチャが出てきたらいいなと思う次第なわけですが、 真面目な話、あんま使われすぎると変動価格の底上げがされちゃうので、発表自体するべきか迷った部分もあります。どーーー考えてもコソコソやってた方が短期的にみて得
新卒インフラエンジニアを育成した話 | 外道父の匠
お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から本番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は本人の希望以外に人事部判断や
エンジニアがアウトプットすべき理由 | 外道父の匠
ブログが流行りだして10年以上が経とうとしているのに今更な内容ですが、エンジニアがブログを書く書かないについて再考する機会があったので、書き留めておきたいと思います。 書く人にとってはメリットがわかってるし、書かない人にとってはデメリットを流せるし、ぶっちゃけ好きにすればいいだけではあるのですが・・・ アウトプットとは ”発信”の方がしっくりくるのでどっちも使いますが、ここでは一般的っぽい”アウトプット”としています。私が思いつくアウトプットとは、 技術ブログを書くこと Wikiに手順やバッドノウハウをまとめること Twitterやコミュニケーションツールで短文メッセージを投稿すること 登壇発表すること 講師やメンターとして育成すること 書籍や連載を執筆すること ソースコードを公開またはプルリクすること で、どれも社内／社外どちらでも問わない、といったところです。ただし、社内におけるコード
エンジニアの評価基準とキャリアパスのお話 | 外道父の匠
春になって暖かくなると、ついつい意識が高ぶってしまいますね。 今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。 はじめに 新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。 ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに（その過程で苦しむのは別として）、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前
2014年からはじめるAWSリンク集 | 外道父の匠
ガチのAWSド素人が年末に調べまくった、AWS関連のリンク集です。 まだまだ調査中なので随時追加する予定ですが、広深くてキリがないのと、年始一発目の目覚ましエントリということでいってしまいます！ はじめた目的 多数のスタートアップにおいて、インフラ専門のエンジニアが付かなくても、小～中規模程度まではそのチームでインフラ面を完結できるようにしたい。 …ということで、今の時代に合わせて簡単・安価・拡張性・耐障害性…を満たす環境を考えるべく、ひたすら知識をかき集めることにしました。考えた構成などについては別途書きたいと思います。 また、遡って調べるほどに出来と進化速度に感心するとともに、情報消費期限がせいぜい２年だと感じ、ほぼ２年以内の情報をもってこのような臭ぇタイトルにしています。 目次 ドキュメント アーキテクチャ クラウド全般比較 クラウド性能比較 費用／スペック ネットワーク 基本インス
エンジニアの成長と反抗期 | 外道父の匠
最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
