タグ

ブックマーク / blog.father.gedow.net (12)

  • システム開発の成功を導く勘所 | 外道父の匠

    最近、システム開発はこうあるべきだよなって考えていたのと、他所のエンジニアリング文化についての記事を見たことから、自分にとっての今の理想と現実の間について整理して吐き出しておきたくなりました。 所詮理想ではあるものの、自身の環境におけるベストに近づけようとする思考や、ベストに程遠い状況を認識する、ということには意味があるのではないかと思う次第です。 はじめに 自分は100%WEB系出身ですが、全く異なる文化である SIer 方面のお話を読むのはわりと好きで、これらは興味深く読ませてもらいました。 誰も教えてくれないSIの質、SIerの世界観 日SIer技術力の低さの要因から考えるアメリカソフトウェアの強さ – きしだのHatena プログラミングが設計作業であるという話 – きしだのHatena ソフトウェアの「詳細設計書」とはなんなのか – きしだのHatena だいたい SIe

    システム開発の成功を導く勘所 | 外道父の匠
  • AWS VPCルーティングの基本から発展構成例 | 外道父の匠

    久々に図を書きたくなったので、今回は AWSVPC ネットワークの主にルーティングについて雑談気味に振り返っていきたいと思います。 基的なところから、少し発展させた構成はどう実現するのか、ってのを学習用教材風にお絵かきしていきます。 はじめに 最近、実現できると思ってた部分が1つ通らなくて、詰んだかと一瞬諦めかけたところで、10分間くらい思案したらズバッと解決できて気持ちよかったんですよ。 我ながら物凄い泥々の技術を駆使して、発想通りにAWS仕様を回避したネットワークを構築してしまった。泥臭すぎてとてもブログに書けないけどっ…自分の中では満点かつスタイリッシュっ — 外道父 | Noko (@GedowFather) July 7, 2023 元々泥臭いエンジニアリングが得意だったとはいえ、こういう発想の展開力はクラウドだけ真面目にイジってても身につきづらいだろうな、と思い、そうい

    AWS VPCルーティングの基本から発展構成例 | 外道父の匠
  • ミドルウェア性能検証の手引き | 外道父の匠

    インフラエンジニアの多分、華形のお仕事の1つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk

    ミドルウェア性能検証の手引き | 外道父の匠
  • AWSにおけるSSL証明書の基本的な取扱い | 外道父の匠

    多くの企業が、今年中にWebサービスの暗号化を進めなくてはいけなくなったかと思います。 Webに接続するiOSアプリは2017年1月からHTTPSの使用が絶対条件になる、デベロッパーはご注意を | TechCrunch Japan ということで、基的な内容ではありますが、AWSにおけるSSL証明書の扱いについて復習してみます。 AWSで扱う証明書の種類 ここでいう種類とは、EV SSL だの ワイルドカードだの、証明書の製品としての種類ではありません。 1つは AWS Certificate Manager(以下、ACM)の無償証明書、もう1つは従来のSSLサーバ証明書販売サイトで購入する有償証明書、の2種類となります。 それぞれの証明書を、AWSのリソースにどのように登録し、運用していくかについてまとめていきます。 ACMの証明書を利用する 2016年1月にリリースされ、5月にはTok

    AWSにおけるSSL証明書の基本的な取扱い | 外道父の匠
  • AWSの複雑な仕組みをTerraform化で紐解く事例 | 外道父の匠

    インフラエンジニアも、そうでないエンジニアも、程度の差こそあれAWS(パブリッククラウド)の知識は欠かせないものになりつつあります。しかしながら、わず嫌いだけならまだしも、AWSにそこそこ取り組み続けているのに、しばしば嫌気がさすことすらあるのは、AWSの複雑さが原因の1つであるといっていいでしょう。 今回は、そんな複雑な仕組みの一つを、Terraform用にコード化することでココロのスキマ、お埋めします。 Infrastructure as Code の過程 Infrastructure as Code によって、手動管理をやめて自動化することのメリットは言うまでもないですが、今回は自動化する過程にこそ非常に大きなメリットがある、という視点にスポットを当てていきます。 AWSは多機能で便利であるがゆえに、複雑です。そして、複雑であるがゆえに、お客さんに簡単に扱ってもらえるよう、操作が簡

    AWSの複雑な仕組みをTerraform化で紐解く事例 | 外道父の匠
  • systemd時代に困らないためのlimits設定 | 外道父の匠

    数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール/SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上

    systemd時代に困らないためのlimits設定 | 外道父の匠
  • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

    RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

    現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
  • Mackerel Meetup #1 Tokyo に参加したり使ってみた感想 | 外道父の匠

    はてなMackerel は気になっていたので登録はしていたのですが、ウチのお母さんがこのイベントに参加することになり、その勢いで俺と息子(4歳0ヶ月)もいくことになりました。 Mackerel Meetup #1 Tokyoを開催します! – mackerel.io ブログ そのため、あわてて実際に Mackerel を使ってみて感想をメモっておくとかしておいたのですが、懇親会ではずっと息子と遊んでいたので、こちらに考えたことを書くことにします。 イベントの内容 これについては早くもまとめてくれている方々がいるので、こちらをどうぞ。 Mackerel Meetup #1 Tokyo の感想まとめ #mackerelio – Togetterまとめ Mackerel Meetup #1 に行ってきました #mackerelio | こえむの編集後記 はてぶ発の監視サービスを中の人が語る!

    Mackerel Meetup #1 Tokyo に参加したり使ってみた感想 | 外道父の匠
  • エンジニアの成長と反抗期 | 外道父の匠

    最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う? と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい?というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する(=仕事したくない)来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3~5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥/改悪サービスに

    エンジニアの成長と反抗期 | 外道父の匠
  • これからはじめるインフラエンジニア 発表資料 | 外道父の匠

    新卒採用のイベントで『知的ヘンタイ六番勝負』というのをやっていまして、その『第三戦 大規模インフラ・解析勉強会』にてインフラについて話してよ、と人事オファーをいただきまして発表した次第でございます。 エンジニア志望とはいえ、不特定多数の人間に対してインフラの話と一口で言われても、誰が何をどれくらい理解してるのかわからないので厳しい案件ではありましたが、せっかく来ていただくので真面目に張り切った結果、質疑応答含めて1時間弱に渡る発表+風邪でノドが潰れた資料がこちらになります。 補足 新卒の方々に向けて これまで新卒の人に関わる機会がなく、インフラについてどの程度理解があるのか全くの不明でしたが、思っていたより勉強しているなという感触と、良いエンジニアになれそうな匂いを発している野郎も結構多かったな、という印象でした。 資料でも触れてますが、WEBエンジニアを目指した時に、何を武器に何エンジニ

    これからはじめるインフラエンジニア 発表資料 | 外道父の匠
  • キャパシティプランニング 発表資料 | 外道父の匠

    久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを1つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい

    キャパシティプランニング 発表資料 | 外道父の匠
  • 原因調査用Linuxコマンド | 外道父の匠

    サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 <追加したコマンド> * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot

    原因調査用Linuxコマンド | 外道父の匠
  • 1