ブログが続かない人のブログ

技術ネタについて書いていきたいです。

「Webエンジニアが知っておきたいインフラの基本」を読んだ

Webエンジニアが知っておきたいインフラの基本

Webエンジニアが知っておきたいインフラの基本

この本、前から気になっていて、いつか読むぞ!と思っていました。やっと読んだので、感想をまとめておこうと思います。

一言で言うと、自分にはまだ早かったなという印象です。

自分の過去の投稿を見てもらえれば分かる通り、サーバ/インフラ系の本をいくつか読んできたのですが、それらのどの本よりも情報量が多く(ページ数も多く)、かなり内容が濃いためなかなか読み進められませんでした。 「サーバ/インフラを支える技術」をさらに詳しく、実践的な面も含めて書いたのがこの本という感触なので、一度読んで終わりではなく、「サーバ/インフラを支える技術」と合わせて複数回読んで徐々に理解していくのがいいと思いました。

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

別にこの本のステマをしようとかいうわけではなく、単純にそう思ったから書いているだけなので、あしからず。

内容的には、前半で基礎知識を詳しく解説し、後半でインフラの構築の仕方、監視の仕方、チューニングする際のボトルネックの見つけ方が載っています。

基礎知識の章で驚いたのは、サーバのスペックについての内容で、CPUやディスクなど、各パーツの選び方が載っていたことです。インフラとはなにかを知るだけでなく、実際に自分で用意する際に役立つように書かれていることに驚きました。 実際自分はそこらへんの知識が皆無なので、まったくついていけませんでしたが...

また後半でも、Howtoだけでなく、監視の章では監視サービスを実際に使ってみている様子から、グラフのどこが何を示しているのかを解説してくれていたり、チューニングの章ではコマンドと入力結果、さらにその入力結果からなにがわかるかが書かれています。 「サーバ/インフラを支える技術」でも、同じようにコマンドと入力結果から考察をする箇所はあるのですが、こちらの本の方が色も見やすかったり、説明がわかりやすいです。 自分は一度読んだだけではしっかりと理解という段階まで至れなかったので、実践しながらもう一周してみたり、もう一度「サーバ/インフラを支える技術」を読んでみたりしながらじっくり理解を深めていこうと思いました。

それでは良いお年を。

「サーバ/インフラを支える技術」を読んだ

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

この本は、以前紹介した、「大規模サービス技術入門」をさらに詳しく解説した本です。

tsukumaru.hateblo.jp

最初の3章でインフラを構築するための基本となる、冗長化、負荷分散について詳しく説明されています。
冗長化とはなんなのか?なぜ必要なのか?から入っていき、冗長化するためにはなにが必要かという風に話が進んでいきます。
最初に用語集がついているくらい、初心者に優しい本ですが、話が進んでいくと、サーバのconfigの記述例が出てきたり、コマンドの出力例を見ながら負荷分散について考えたりと、ある程度知識がある人でも楽しめる内容になっています。

この本の2章でMySQLレプリケーションの話が出てくるのですが、自分がここを読んでいるときにちょうど業務でレプリケーションの知識が必要になりました。
レプリケーションの大体の概念はわかっていましたが、マスターからスレーブに対してデータがどのようにコピーされるのか、マスターからコピー済みのデータかどうかはどのように判断しているのかなどなど、知らなかったこともたくさんあり、とても役に立ったのを覚えています。

4章はチューニングについての話です。
負荷分散といっても、なんでもかんでも分散すればいいってもんじゃないんだ!1台の性能を十分に引き出さないと意味ないんだ!(意訳)
という言葉から始まり、「推測するな、計測せよ」という格言をもとに話をすすめていく感じから、チューニングに対しての気合が感じられます。(多分)

サーバの負荷を見る際に有効なコマンドの紹介(topやsar, vmstat)から始まり、コマンドの出力を見ながら、なぜこのような出力がでるのかをライブラリの中身を見ながら解説していきます。
ただ単に「このコマンド使えばこういう出力でるから、負荷見るときは使うように」というような薄い内容ではないのが、自分はすごく好印象でした。
まず何からすればいい?CPU負荷が高い場合は?I/O負荷が高い場合は?など順に負荷の原因を解明していくプロセスが解説されていて、とてもわかりやすいです。

5章は、サーバ監視の話です。 Nagiosを例にとり、実際に使っていく中で、サーバ監視のあれこれを解説していきます。この章はあまり自分の興味がわかずざっとしか読めていません...また時間があったら読もうと思います。
Nagios - The Industry Standard In IT Infrastructure Monitoring

まとめ

自分はサーバ/インフラの初心者だったため、「大規模サービス技術入門」から読んだ方がいいかなと思っていましたが、「サーバ/インフラを支える技術」を読んでみると、案外こっちの方がわかりやすくためになると感じました。「大規模サービス技術入門」の方ははてなインターンシップをまとめた形のため、勉強のために読むという感じだと物足りないと思います。
インフラ系の業務で困った時の辞書的な役割をしてくれる本だと思うので、ぜひ一家に一冊あるといいのではないでしょうか。

「問題解決」基礎講座を読んだ

新人コンサルタントが入社時に叩き込まれる「問題解決」基礎講座

新人コンサルタントが入社時に叩き込まれる「問題解決」基礎講座

この本は、問題解決とは何かや、問題解決するために必要なプロセスについて詳細に書かれています。 問題解決のための思考法を学びたい人、一度自分の考えを整理したい人などにおすすめです。

「新人コンサルタントが入社時に叩き込まれる」というタイトルはついていますが、難しい内容ということではなく、問題解決の手法について優しく書かれた入門書です。 中の例が少しコンサルタントっぽい例を使っているというだけです。

感想

この本のいいところは、本全体を通した流れがわかりやすいという点と、1トピックを見開きに収めているという読みやすさです。
問題発生から問題解決までの流れを6つのプロセスに分割し、本の序盤で各プロセスをざっと眺め、後半で一つずつ詳細に見ていくという構成になっているため、いまどこのプロセスを見ているのかがはっきりわかり、とても理解しやすく読みやすいです。
また、本の最初から最後まで、左ページにトピックの詳細、右ページに図解という構成を続けているため、すらすらと読み進めることができます。

問題解決の本を読んで、いいところが読みやすさかよという方もいるかもしれませんが、大抵、この類の本は文字ばかりであったり、図が付いていてもよくわからないといったことが多いのに対し、
この本は1トピックで言いたいことを的確に図で表しており、本文も1文でまとめられるほどの情報量に抑えてあります。
「問題解決本」と聞いて、少しびびっていた僕は、この構成にかなり感動しました。

肝心の内容についてですが、かなり丁寧です。
これは良いニュアンスと悪いニュアンス両方を含めています。
良いニュアンスとしては、問題への向き合い方、考えの進め方(プロセス)などが、各プロセスごと細かいトピックにわかれており、具体例とともに示されているため入門者にもわかりやすく書いてあります。データの見方、アイデアのまとめ方などから、原因の掘り下げ方など細かいことから大きなことまでしっかりと書いてあります。
逆に悪いニュアンスとしては、ふせんのおすすめサイズといった、そこまで書くのか!と思うようなことまで書いてあります。自分が読んでいる時に少し気になってしまったため、ここは読む人の好き嫌いがわかれそうだと思いました。

まとめ

問題解決のプロセスを学ぶためには、まずこの本を読むといいのではないでしょうか。

大規模サービス技術入門を読んだ

この本は、株式会社はてなインターンシップの内容をもとに書かれた本で、大規模なサービスを運営する上で、蓄積されていくデータをどう処理していくのが正しいのか、ということについて書かれています。

インターンシップの内容ということもあり、ビッグデータとはどの程度の規模のことをいうのか?メモリとディスクの違いはなんなのか?など、かなり基本的なところから説明されています。

僕はサーバ/インフラ系の知識を基礎からつけたかったので、この本はかなり役に立ちました。

この本の内容はざっくりわけるとこんな感じになると思います。

講義形式で進んでいき、途中で実装課題もでてくるため、あたかも自分が学生に戻ったかのような気分で読むことができます。

サーバ/インフラ系の知識をつけたい方、基礎からおさらいしたい方など、一度読んでみることをおすすめします。

なるほどデザインを読んだ

みなさんは「この広告すごい引き寄せられるなぁ」とか、「この雑誌は読みやすくて好き!」などと思ったことはないでしょうか。

逆に、 「この本どこを見ればいいのかわからない...」や「チラシがカラフルすぎて目がチカチカする...」などと不満を口にするときはないでしょうか。

その広告はなぜ引き寄せられるのでしょうか。その本はなぜどこを見ればいいのかわからないのでしょうか。

みなさんが思っているそんな感情を言語化する助けをしてくれるのが、このなるほどデザインです。

この本は、もとは新人デザイナー向けに書かれた本ですが、デザインの知識がなくても読めるデザイン入門書になっていて、

  • デザインとはなんなのか?

  • デザイナーは普段どういったことを気にしながらデザインしているのか?

  • 自分がデザインするときのポイントは?

など、初心者なら知りたい内容がぎゅっと詰まっています。270ページほどありますが、絵や写真がたくさん使われているため、本が苦手な方でも読みやすいと思います。

本全体は3章構成になっており、だんだんとデザインの世界に踏み込んでいくような流れになっています。

Chapter 1では、雑誌の1ページを例にとり、いろんなパターンでデザインした場合の良し悪しを見ていきます。

なんとなく「見やすい」と思っていたのが、「大きな文字サイズ」であったり「種類別の色使い」など具体的に言語化されているので、すごくなるほどと思わされます。

Chapter 2では、デザイナーが心得ているデザインのコツが紹介されています。

  • どの情報がより大事か?

  • 主役となる情報はどれか?

  • デザインを人にたとえてみる

などなど、言われてみるとたしかにと思うことが書かれており、ここもなるほど連発です。たしかにと思うということはデザイナーの方たちは私たちの心などお見通しというわけなんですよね...

Chapter 3では、デザインの詳しい話に入っていきます。

  • 書体が違うと伝わる意味はどのように変わるのか。

  • 狙った色を作るためには?

  • 主役を引き立てるページの構成は?

などなど、人にメッセージを伝えるために、ここまで考えられていたのかとデザインの奥深さを痛感させられます。

僕はデザインはまったく経験がありませんが、とても楽しく読めました。日々目にする広告やチラシなどをちょっと違う目線から見ることができそうです。

まだ読んでない方はぜひ読むことをおすすめします。

結局一番二日酔いに効くモノってなんなんだ

どうも今日1日二日酔いでした。

というのも、実は今月に誕生日を迎えるのですが、それに伴ってサークルで誕生日会を開いていただきました。
まぁ、大学生の集まりにはお酒がつきもので、その日も鏡月が1本ありました。
誕生日会を開いてもらった立場としては飲むしかない!と思うわけです。
飲みます。
飲みます。
飲みます。



全部飲みました。

酔い潰れました。

部屋出ししてくれた後輩くん、トイレにこもって本当にごめんなさい。
鏡月1本くらいいけるだろって思ってましたがけっこうダメージが大きかったです。

そして家に帰り、二日酔い対策に寝る前に水をがぶ飲みしベッドに倒れこみました。

〜〜翌日〜〜

気持ち悪い!!!!!

最強に気持ち悪くていそいでトイレにかけこみました。

今までこんなに気持ち悪くなったことはありませんでした。
とにかく楽になるために二日酔いに効く食べもの、飲み物をググったのですが、
"ハチミツ"とか、"シジミの味噌汁"とか、"果汁ジュース"とか様々な情報がでてきて一体どれが一番効くのかわからん!!!1という感じでした。

コンビニでシジミの味噌汁、肉うどん、オレンジ100%ジュースを買ってきて食べたのですが、それでも気持ち悪く良くなる兆しがありませんでした。

そこで、僕は思い出しました。いままで飲み会の後に気持ち悪くなった時にカレーうどんを食べて回復していたことを。
僕の大学の近くにはカレーうどん専門店があり、そこのカレーうどんを飲み会の翌日には食べていました。
いままでに比べてかなり気持ち悪かったためカレーうどんを食べる気分ではなかったですが、無理やり食べてみることにしました。

すると...

治った!!!!!!!!!

治りました!!!!!!!!!

カレーうどんの力強すぎる...食べてから全然気持ち悪さは感じなくなりました。
自分にはカレーうどんが効くみたいです。


世間一般に言われている対処法もいいですが、なにか自分に合わせた対処法を持っておくというのも大事なのかもしれません。

Fringe81で3ヶ月のインターンしてきた

突然ですが、3ヶ月に渡るインターンが終了しました。
実は10月からFringe81という会社で3ヶ月間の長期インターンさせてもらっていて、ちょうどクリスマスの日に卒業したというわけです。

なぜFringe81にしたのか

なんでFringeにしたかを振り返ると、まずサポーターズのイベントで会ったのが最初で、そこから1dayインターンに参加することになりました。
まず六本木ヒルズに会社があるというだけでオシャレな感じがするしすごいドキドキでした。
そんなインターンの内容はチームに分かれて設計の問題を複数解き、より多く解いたチームは景品がもらえるというもので、
チームCATとチームタンドリーに分かれたんですが、我らチームタンドリーは見事勝利し景品をもらいました。(ちなみになんでチームタンドリーかというと、自分の最近作った料理がタンドリーチキンだったからです)

終了後、「長期インターン興味ある人は興味ありますって書いていってね」という言葉を聞き、ミーハーな僕は長期インターンという言葉にひかれて応募しました。
もちろんちゃんとした理由もあって、
・設計にもっと詳しくなりたい
・アドテクが何者かよくわかんないから理解するきっかけとして
・長期インターンすればwebの力つきそう
という以上3つが動機でした。(よくあるこの会社で働きたいから!!みたいな理由じゃなくてすいません...)

それでいろいろ面接などをした後、無事参加!という形になったんです。

なので多分1dayインターン行ってなかったら参加してなかったですね...笑

長期インターンでなにをしたのか

まず最初は基礎的な部分からでした。
gitの使い方、JavaScriptMySQL、設計の復習、Scalaの特訓、PlayFrameworkの使い方...
といったようにフルコースな内容で勉強していきました。
その人の力に応じてカリキュラムを組んでくれるので何も心配いりません。
ぼくはここでScalaにはまってしまい、コップ本をAmazonでポチりました。
Amazon.co.jp: Scalaスケーラブルプログラミング第2版: Martin Odersky, Lex Spoon, Bill Venners, 羽生田 栄一, 水島 宏太, 長尾 高弘: 本
(ちなみにまだ4章くらいで止まってます...)

ここまでやった内容をふまえての後半に入る訳です。

後半は実業務に入らせてもらって開発していました。
(前にインターンに来てた人たちはここで独自のプロダクトを作っていたそうです)
ScalaやPlayFrameworkに慣れ始めたところだったので、まずソースコードを理解するのが大変でしたが、社員さんが優しく教えてくださったためなんとか自分でも理解できました。Scalaにはまってたから頑張れたってのもあるんですかね。
やっていたことは、新しい部分の実装→コードレビューを受ける→修正という流れを繰り返しながらプロダクトを完成させていくことでした。
レビューで大量の指摘をもらうことが多々ありましたが、その度に質問したりしながらも修正することで自分の技術力アップにもつながったように思います。なかなか学校だとレビュー受けないのでいい経験でした。
いろいろありながらも最後はリリース作業までいくことができ、「君に任せてよかったよ」と言われたときはかなり感動しました。
こうして実業務に入らせてもらえたことで、自分の将来像をしっかりイメージできるようになれたのは大きい収穫でした。

まとめ

Fringe81でのインターンはとても自分の成長の糧になるものが多かったです。
前述のこのインターンでの3つの目標もほぼ全部達成することができました。

Fringe81ならではの特徴として

  • エンジニアの机に仕切りがない!
  • アドテク説明会を開いてくれる
  • Scalaが勉強できる
  • 六本木の美味しいお店に連れて行ってもらえる(エンジニアだけでなく営業側の人たちともご飯に行ける)
  • 合宿やボウリングといった行事にも参加させてもらえる

などなどといったものがあると思います。少数精鋭なエンジニアの方たちだからこそ、一人一人と深く関われたと思います。

僕は単騎突入だったので若干寂しかったですが、それでも社員の方々が優しくしてくださったおかげでとても楽しいインターン生活を送れたので、
インターンどこ行くか迷ってる人は、一度Fringe81を考えてみてもいいと思います。友達とか誘ってもいいと思います。(なんかすごい宣伝になってしまった...)

Fringe81の方々、本当にいろいろありがとうございました!!

これからはここで得たことを糧にして就活頑張ります_(:3 」∠)_