エンジニアの成長における過去と現代の違い | 外道父の匠
自身の過去の成長過程と現在の環境を思い浮かべたときに、得やすいもの得づらいものの違いを強く感じ、良好な成長のために一考してみた次第です。 といっても既にある Tweet のセルフまとめに、思い出と昔話なポエムを追加したようなチラ裏回です。 時代の変遷によるステータス変化 要約すると、現代は技術力の向上に必要な環境と既定路線があって向上速度が早いのに対し、昔（2010年以前とか）は頭を悩ませまくって乗り越えるべき壁が大量にあったおかげで解決力は相当鍛えられたよねってところ。 個人的には誰であれ、今！自分が！解決しないと！詰んでしまう!! てかもう詰んでるだろコレ!!!! って状況でひたすら悩んでから、寝て起きたら解決したよぉ！みたいのを体験してほしいし、一度は死の淵まで行ってこいって思っている — 外道父 | Noko (@GedowFather) July 17, 2024 これについて、
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 の話にな
エンジニアの職人芸を継承すべし | 外道父の匠
『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。 そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。 職人芸とは 言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。 そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。 システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあ
Kubernetes、やめました | 外道父の匠
最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ
Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の２つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
エンジニアの成長と反抗期 | 外道父の匠
最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに
これからはじめるOpenStackリンク集 | 外道父の匠
潤沢な開発環境でも構築しようかなという目的から、OpenStackに触れ始めました。 システム全体の感覚を掴むのに多少時間がかかりましたが、整備された英語マニュアルと 既に数多くある日本語情報のおかげでかなりスムーズに会得できてるのではないかと思います。 あまりまとまりないですし、Debianよりになっていますが 以下、OpenStackリンク集になります。 目次 公式 概要 構築全般 Open vSwitch Quantum Keystone Glance Cinder Swift Ceph VNC Image Quota その他 公式 OpenStack Open Source Cloud Computing Software 日本OpenStackユーザ会 – Japan OpenStack User Group Japan (JOSUG) openstack.jp 技術文書、プレゼ
ドリコムのソフトウェア選択のお話 | 外道父の匠
mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。 こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。 OSの選択を振り返る 2001年あたりから覚えている範囲でザッと振り返ると、 RedHat 7-9 FedoraCore 1-3 Debian 3-6 CentOS 4-6 という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。 こういう選択をしていった理由は、 まずRedHat～F
これからはじめるインフラエンジニア 発表資料 | 外道父の匠
新卒採用のイベントで『知的ヘンタイ六番勝負』というのをやっていまして、その『第三戦 大規模インフラ・解析勉強会』にてインフラについて話してよ、と人事オファーをいただきまして発表した次第でございます。 エンジニア志望とはいえ、不特定多数の人間に対してインフラの話と一口で言われても、誰が何をどれくらい理解してるのかわからないので厳しい案件ではありましたが、せっかく来ていただくので真面目に張り切った結果、質疑応答含めて１時間弱に渡る発表＋風邪でノドが潰れた資料がこちらになります。 補足 新卒の方々に向けて これまで新卒の人に関わる機会がなく、インフラについてどの程度理解があるのか全くの不明でしたが、思っていたより勉強しているなという感触と、良いエンジニアになれそうな匂いを発している野郎も結構多かったな、という印象でした。 資料でも触れてますが、WEBエンジニアを目指した時に、何を武器に何エンジニ
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
第2回 ioDrive+MySQL勉強会 発表資料 | 外道父の匠
GMOさんのところで、ioDrive＋MySQLの発表をしてまいりました。 前回のFluentdから中4日で登壇という恐ロシアなスケジュールに真っ白な灰となっております。 １番手だったので基本を抑えつつ尖り気味のところまで入れてしまったせいで、40分のところを53分使い、さらに質疑応答で1時間以上になり、他の発表者や参加者にご迷惑を、そしてピザを冷えさせて申し訳ありませんでした。が、資料自体はぼちぼちな出来になったと思いますのでサクッと公開しておきます。 事前にページを削りとってしまったり、早送りで説明してしまった部分があるので補足したいところなのですが、燃え尽き症候群中なのでMySQL関連は後で少しずつ書いていけたらと思います。 戦利品 Fusion-IO社のサンタクロースと言われる例の方が、登壇者にプレゼントをしてくれました。 ゴルフシャツですが Mサイズ Woman用で、微妙に形が女
Fluentd Meetup #2 発表資料 | 外道父の匠
このブログやTwitterをご縁に、Fluentd meetup in Japan #2 で登壇させていただくことになり、張り切って発表してきました。 発表資料はアニメーションを多様していたのでSlideShareだとわかりづらいかもですが、アップロードしましたので御覧くださいませ。 内容の補足 いくつか質問を受けて答えたりTwitterで見た点について、資料の補足をしておきます。 Agent -> Collector通信経路について Q. なぜVPNにしなかったのか A. VPNは可用性／負荷分散性の点で弱いため。また、VPNサーバや他にもGatewayなど余計な経路を通ることになり無駄である。Agentの増加に対してボトルネックができない構成にしたかったため。政治的な理由で、ある環境だけVPNをはれないといった場合もあり、総合するとGlobal＋暗号化 が良い落とし所だった。 圧縮／暗
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
