Browse Tag: engineer

hbstudy #8 に行ってきた

会社のインフラをおもに担当している同僚を誘って、hbstudy #8 http://atnd.org/events/3092 に行ってきました。今回は、kazuho さん、mizzy さん、という豪華な講演だったので参加人数も 120 名くらいと、とても大人数で驚きました。

今回の講演のスライドは、おそらく公開されるのではないかと思いますが、今回の hbstudy #8 ではツール以前にインフラエンジニアとしてどんなところを目指すか、どのような姿勢でインフラを管理するかといった精神論的な考えというか思想が、とても勉強になりました。

まず、インフラにかかわらず、何言にも共通する思想は、

楽をすること

につきると思います。楽をするための苦労は惜しまずに、楽をするためのツールを自作したり、オープンソースのツールを使ったり、楽をするにはいろいろな方法があります。まず考えることは、楽をするために何をすることなのかなぁと思います。楽をするというと、なんだか怠け者のような印象をもたれることもあると思いますが、楽をするために新しい手法を取り入れていることは大事だと思います。

その次は、インフラエンジニアとしての大切だったと思った思想は、次のとおりです。

  • インフラに導入するツールは、なるべくシンプルなものにする
  • 自作ツールの場合、なるべく同じ技術を使ったツールで統一する
  • ある程度、基本知識がある人なら、自分が管理しているインフラを管理することができるようにする

まず、前提となる知識を習得するのが困難だったり、使い方は複雑なツールは使わないということです。やはり、とても便利なツールでも複雑なツールを導入してしまうと、自分はいいのですが他の人に引き継ぐことになったときなどに説明する手間がかなりかかると思います。また、決してオープンソースのツールだけに選択肢をおかずに機会損失や管理コストなどを総合的に比較して商用ツールも検討するといったこともあるかと必要な場面があると思います。

その次ですが、kazuho さんが基本的にとてもシンプルな自作ツールでインフラを管理しているという話の中で登場してきたツールはほとんど perl で書かれていました。自作ツールでも、シェルスクリプトだったり、C++ だったり、ruby だったり、と実装している技術はバラバラだと、すべての知識が必要になってきます。こうした自作ツールは、perl など1つの実装にまとめることで perl さえ分かれば自作ツールのメンテナンスや改良もできます。最近の Linux の場合、Linux Standard Base (LSB) | The Linux Foundation という規格があるこの規格によると perl や python は最初からインストールされています。残念ながら、ruby や PHP は入っていないので、ruby や PHP で作るときにはパッケージのインストールが必要になります。最近のサーバは、とても早いのでわざわざ C++ などで作成するよりも LL で十分なことも多くなってきていると思います。個人的には、ruby を愛用していますが、python にしたほうが標準インストールされているという観点でみるとありかなと思っています。

最後に、自作ツールでもあまりオレオレ仕様的なツールは作らずに、他のツールの思想や考えたにのとった自作ツール、定番といえるオープンソース、だけをできるだけ組み合わせて、かつシンプルに形でインフラを管理しておくということです。シンプルにしておけば、日常業務の中でも毎日やることが単純になったり、業務レベルで他の担当者と共有することも比較的容易なのでないかと思います。

今回の hbstudy では、このような考え方というか思想が大事なのではないかと感じました。僕が管理しているインフラも、この思想に基づいていけるように日々改善を重ねいたいと思いました。

インフラエンジニアになろう!

おそらくこんなインターネットの端っこにあるブログで発してもあまり効果はないと思うけれど、個人的に感じるインフラエンジニアの魅力を書いてみたいと思います。

最近、このブログがほぼインフラに関する内容なのは、僕はインフラエンジニアだからだ。

僕は前職ではとある工場のようなところで働いていていわゆる普通に組み込み系のエンジニアだった。Win32 アプリケーションから Java アプリケーションから Structs を使った Java Web アプリケーションからファームウェアまで一通りの仕事をしたことがある。

そんな環境から一転して、今はとあるコンシューマサービスのインフラエンジニアをやっている。インフラエンジニアをやっている理由は、特に上から指示されたのではなく、まともなスキルもないのに自分で志願してやっている。

僕がどうしてインフラエンジニアをやっているかというと理由は、次のとおり。

  • おそらく誰もやりたがない仕事であること(実際に志願したときには誰もやりたがってはいなかった)
  • 動いて当たり前だと思われるが、当たり前でもそのビジネスを支える仕事をやってみたかった
  • 個人的にメールサーバやウェブサーバを構築するのが、好きですこし前まではこのブログのシステム管理者だった
  • 自前のサーバを構築するのが好きだった(特に FreeBSD)
  • アクセスの多いサーバを自分で考えて構築したなかった(実際には失敗の連続中だけれど)

と思って始めたが、実際に初めてみると正直次のような不満もあった。

  • 深夜作業が多い、分野外の人(例えば社長など)から評価されない、動いていて当たり前止まるとどうしてという顔をされる
  • サーバ代などの投資対効果が分かりにくい(どうしてそんなにサーバ代に投資したのにパフォーマンスが上がらないのかと疑問を持った顔をされてしまう、自分で説明できないのはよくない)
  • 自分がベストだと思っているサーバや技術を選択しているが、その選択がたった一人なので本当に正しいか自信がない
  • インフラだけやろうかと思っていたけれど、実際にはインフラ上で動かすプログラムまで責任を持ってみないといけない(インフラだけというのは調子が良すぎた)

で、こんなことを考えつつ、誰にも話す機会もないので、自分で試した技術や考えたことなどをこのブログで頻繁に公開している。あまり誰も見てくれていないとは思いつつも。。。どちらかというとたくさんの人に読んでほしいという願望があるものの、実際には自分の考えをまとめるかっこうの機会になっている。

世間を見渡してみると、数多くの会社でインフラエンジニアを募集している。

かなり偏っているかもしれないがが、他にもたくさんの会社でインフラエンジニアを募集しているし、その需要は IT システムがある限りなくらないと思う。

Google も Yahoo! も Facebook も mixi もニコニコも、数多いのメガサイトに共通しているのはそれを支える超優秀なインフラエンジニアがいてそれを支えているということ。それは、Facebook の新しいリクルーティングビデオでも公開されている。このビデオではちらっと Facebook の DC の映像があってサーバを垣間見ることができる。

個人的に思うのは、Web アプリケーションエンジニアというスキルがあってもインフラのことが分からなければあまり意味がないと思う。インフラも分かる Web アプリケーションエンジニアというのは本物のエンジニアであると思うし、どちらもかけてはいけないスキルだと思う。とはいっても同時にはすべてできないので、どちらから入るべきか考えるのは大事だと思う。僕はインフラエンジニアから入ることを選んだ。

今の僕の仕事は、次のとおり。

  • 自分でサービスに必要なサーバを限られた予算の中から選定する
  • サーバを注文する
  • サーバを自分一人でマウントする(一昨日は、一人で 1U サーバ 8 台ダンボールから出してマウントした。。。)
  • マウントしたサーバをセットアップして、本番サービスに問題の内容に投入する
  • 投入したサーバの効果を数字など社長などから分かりやすい数字データで説明して投資効果があったことを説明する
  • 夜も安心して眠れるようにサーバを冗長化したり、省電力で運用するように頑張る
  • プログラム側もみつつ、サービスが安定して運用するように努める

サーバ/インフラ本も出版されてかなりたつので、この本を読んでインフラエンジニアになろうと思った人は必ずいるはず。さらに、今回の Web+DB Press で mixi のインフラの記事の連載が開始されて、インフラエンジニアに注目する人も多いはず。

インフラを支える仕事というのは誰もやりたがらない分、やりがいのある仕事だと思う。

だから、すこしでも興味のある人はおそらく今この瞬間したチャンスがないからインフラエンジニアになろう!このブログを読んでインフラエンジニアになろうと思った人は、僕と飲みにインフラエンジニアの魅力について語り合いましょう(笑)!

すこしでもブログなどにアウトプットし続けていれば、きっといいことがあるし、何よりも自分のためになる。

さあ、インフラエンジニアを目指そう!!!僕も引き続き、レベルはかなり低いけれども考えずに頑張りまっす。