Fire Engine

化学の修士号→消防士→ITエンジニア(2016年11月〜)

ペパカレのインフラ研修を修了した

どうもつるべーです。
私は2018年3月1日から、GMOペパボ本社にてペパボカレッジ(通称ペパカレ)のインフラ研修を受けており、4月6日に無事修了することができました!
今回は研修で学んだことやこれからやりたいことなどを書いていきます。
以前ペパボへの転職エントリーも書いたので、よければ読んでください!

www.hirotsuru.com

ペパカレって?

ペパカレとは第二新卒エンジニア向け研修のことで、中途で入ってもみっちり研修を受けられます。
私はペパカレ6期生で、これまでWebアプリケーションエンジニアとモバイルアプリケーションエンジニアの採用があったみたいですが、インフラエンジニアのペパカレは今回が初めてだったようです。 ペパボカレッジについては詳しく知りたい方は下の記事を見てください!

www.wantedly.com

やったこと

作業環境ハンズオン

  • zshの導入
  • tmuxの導入
  • ghqとpecoを使ったGit環境の整備(参考

(一言)
ターミナルやエディタ周りはエンジニアにとって最も重要な仕事道具であるため、こだわりを持ってハックすることが大事

Linuxオペレーション基礎

  • Linuxコマンド100本ノック
    • awkコマンドを使ったログの集計
    • grepコマンドによる文字列検索など

(一言)
実際は30本ノックくらいだったかな?一つの処理をするコマンドをパイプで繋いでいき複雑な処理を行っていくところにUNIX哲学を感じた。

オンコール対応

  • 障害原因の調査(ログ・プロセス監視など)
  • サービスの復旧
  • ポストモーテム
作成

(一言)
サンプルのサービス上で意図的に障害を起こしてもらいオンコール対応の疑似体験をした。
障害発生時には「データ(パケット)が流れる順番に沿って調査する」ことが重要だ。

Infrastructure as Code入門

(一言)
いろんな技術に触れまくって超楽しかった。一気に使えるツールが増えた。
Infrastructure as Codeは奥が深いからIaC本を隅々まで読んで復習をしよう。

コマンドラインツール開発

(一言)
初めてコマンドラインツールを作った。Rubyを書くのが楽しくなった。

スクラム研修

  • レゴスクラムを通したチーム開発手法の研修

(一言)
チームでレゴを使って街を作った。大人になってレゴ初めてやったけど普通に楽しい。
チームで作業をするときは、みんなでコミュニーケーションを取り、作りたいものの認識を合わせることが重要だ。

振り返り会

  • KPTを使った週次の振り返り

(一言)
振り返りってこれまでちゃんとやったことがなかったし、その重要性がわかってなかったけど、振り返りの文化はチームでも個人でも超大事だと思った。
何が大事かっていっぱい理由はあるけど「俺たちは前に進んでるんだ」って実感が得られるのが大きいんじゃないかな。

その他(仕事の進め方など)

  • GitHubを使ったPRベースの仕事の進め方
  • Slackの活用方法(スレッドの活用など)
  • コミュニケーション方法
    • 誰かに何かをお願いするときは、いつまでにやってほしいかを明確にする
    • 自分側にあって、相手側にない情報を的確に伝える
    • 遠慮はしない
  • 勉強していて疑問に思ったことはガンガン共有する
  • 何かを習得するときに自分の言葉で説明できるようになる(言語化できること)が重要

(一言)
技術的なところ以外にもいっぱい学びがあるのがペパカレ。

気持ちが変わったこと

自分は成長する存在だと信じられるようになった

これまでエンジニアになって1年間ちょっとの間、自分が成長していると思えなくて悩んでいた時期もあったが、ペパカレでは凄まじいスピードでいろんな技術を習得させてもらったことや、それら学んだ技術を毎週振り返り会で書き出して実感することで、自分の成長を実感できた。
そもそも「自分の成長を信じれないなら、頑張る意味なんてないんだ」と思うようにもなった。

ペパボが大好きだ

  • どんなに小さなことでも褒めてくれる
  • ネガティブな発言はしない
  • みんなと仲良く、でも遠慮はしない
  • 困っているときにいろんな人が手を差し伸べてくれる。
    そんなペパボが大好きになった。

全体を通しての感想

今回のペパカレでのインフラ研修を一言で表現をすると 最高 という言葉しか思い浮かばない。
教えてくださる講師の方々も 最高 、一緒に学ぶ同期も 最高 、会社の雰囲気も 最高 、窓から見える渋谷の街も 最高チリチリネパリコ最高 、最寄りのジムのトレーニング器具も 最高 だった。
ペパカレは本当に頑張る人を支援する仕組みだから、自分と同じようにITとは全く関係のない仕事をしていて、でもITめっちゃやりたいという人にもぜひチャレンジしてほしい。

今後やっていきたいこと

今後は福岡に帰り、インフラ業務をやらせてもらうが、研修でいっぱい学んだとはいえ、広大なインフラの中ではほんの一部であり、まだまだ足りない知識や技術もたくさんあるだろうと思っている。なので、まずはインフラエンジニアとして必要な知識や技術をいち早く習得し、日常的なインフラの業務をこなせるようになることが最優先でやりたいことだ。
その中で、現場の様々な課題に自分自身が直面し、コードを書いて問題解決できるようになりたい。そしてゆくゆくは、自分の得意な領域でかつ誰にも負けない領域を築き上げて、自分にしか作れないものを作ることが夢だ。
あと引き続きベンチプレス150kgを目標に体も鍛え続けたい。

f:id:hirotsuru314:20180408231615j:plain

k近傍法による異常検知のライブラリをmrubyで作ってみた

こんにちは!インフラエンジニア見習いつるべーです。
今回は、mrubyという組込ソフトウェア向けの軽量なRuby言語を使って、k近傍法による異常検知を行うスクリプトを書いてみたので、そちらの紹介です!

目次

なぜ作ったのか

今回は、「何かの問題を解決したい」というよりは、「Rubyの勉強がてらに何か作ってみよう」という動機で作りました。
ただ、一般的なRuby(CRuby)ではなくmrubyを選択したのには理由があります。
私が勤めているGMOペパボでは、mrubyを利用してミドルウェアの振る舞いを設定・制御する仕組み(これを"Middleware Configuration as Code"と呼んでいる)を積極的に導入しており、そこに非常に興味を持ったからです。
下の二つのスライドには、"Middleware Configuration as Code"の概要や事例がまとめられています。

Middleware Configuration as Code // Speaker Deck

Middleware as Code with mruby

作ったもの

ソースコード

github.com

k近傍法に基づく異常検知の理論は最後に書いておくので興味のある方はぜひ!

使い方

mrubyで自分が書いたコードを動かすには、mrubyのコンパイル時に書いたコードを組み込んでコンパイルする必要があります。
したがって、まずはmrubyをコンパイルする環境を用意する必要があります。QiitaにCentOS7上でmrubyをコンパイルして動かすまでの手順を書きましたので、ご参考までに。

qiita.com

mrubyをビルドする前にbuild_config.rbに以下の記述を追加してやると、mruby-knn-detectorを組み込んだmrubyができます。

MRuby::Build.new do |conf|

    # ... (snip) ...

    conf.gem :github => 'tsurubee/mruby-knn-detector'
end

それでは、mirbというCRubyにおけるirbに相当する対話型インタープリタを使って動かしてみます。
※ mruby-knn-detectorは一次元の時系列データの異常検知を行うもので、入力データは一次元配列になります。

$ mruby/bin/mirb
mirb - Embeddable Interactive Ruby Shell

> knn = KNN.new(2, 1)  #(Window size, Number of neighbors)
 => #<KNN:0xdc0fa0 @k=1, @w=2>
> data = [1, 2, 10, 2, 1]
 => [1, 2, 10, 2, 1]
> knn.score(data)
 => [0, 1.4142135623731, 8.0622577482985, 8.0622577482985, 1.4142135623731]

KNNクラスの引数にはスライド窓の幅と近傍数を渡してやり、一次元配列をscore関数に投げ込むと、投げ込んだ配列と同サイズの異常度配列が返ってきます。
(スライド窓や近傍数については最後に解説しています)
返ってきたら異常度配列のうち要素の値が大きいものほど異常度が高いと判断できます。

mrubyに入門するには

mrubyを書き始めるのはCRubyやPythonなどを始めるより少しハードルが高く感じました。それはなぜかというと、コンパイルということに馴染みがなかったからです。私自身ほぼPythonしか書いたことがなかったため、今回初めて自分の書いたコードをコンパイルしました。
それでは、私と同じように「mrubyってちょっと取っつきづらいよ」と感じる方がどうやってmrubyに入門すると良いかということについてですが、私の場合、最初に「WEB+DB PRESS Vol.101」の中で@pyama86さんが執筆された「mrubyを活用したインフラ運用の最前線」を読みました。mrubyの部分は本の中の7ページだけですが、実際にmrubyを利用して開発を行うときに必要な手順がわかりやすく解説されていました。
具体的には、@matsumotoryさんが開発しているmruby-mrbgem-templateを用いたmrbgem開発の基本的な流れが書かれていました。 mruby-mrbgem-templateを用いると、たった数コマンドでmrbgemのひな形が生成されるため、大変便利でした。
mruby-mrbgem-templateの使い方は下の記事に解説がありました。

qiita.com

mrbgemのひな形までできると、あとは普通にRubyを書いていくだけでした。
やりたいことによっては、Linuxシステムコールを利用するような処理をC言語で実装し、C言語のメソッドをRubyから呼び出したりできるようです。
今回私は50行くらいのRubyを書いただけです。

Changefinderとの比較から見るKNNの特徴

mrubyによる異常検知の実装には@matsumotoryさんのmruby-changefinderがあります。今回これとKNNの比較をしてみたいと思います。
用いるデータは、あんちぽさんがmruby-changefinderを使った異常検知例を以前のブログに書いていたので、それを真似てみようと思います。
データの元ネタは「異常検知でGo!」のデータを使っています。
ハイパーパラメータは以下のような値を用いました。(ハイパーパラメータとは人が決定しなければならないパラメータのこと)

# ChangeFinder
cf = ChangeFinder.new(5, 0.01, 10, 0.01, 5)

# KNN
knn = KNN.new(5, 5)

異常検知の結果が以下のグラフになります。比較しやすくするために縦軸は調整しています。

f:id:hirotsuru314:20180401183834p:plain

KNNもなかなかいい形してますね!
ここで両者の違いをいくつか議論します。(アルゴリズム的にどちらが優れているとかいう話ではない)
まず、ハイパーパラメータについてですが、ChangeFinderが5つに対して、KNNは2つしかありません。したがって、ChangeFinderの方が柔軟な設定が可能であり、確率分布がバチっとハマった時は強そうですが、ハイパーパラメータのチューニングが大変だとも言えます。
明示的に確率分布を仮定しない、KNNや特異スペクトル変換などのアルゴリズムは、ハイパーパラメータも少ないですし、様々なデータに頑強な印象です。
ChangeFinderのメリットの一つは逐次的な学習アルゴリズムであるため、初期学習をしておけば、新しい観測点に対して、一つの異常度を返します。そのため、計算も比較的軽量ですし、異常度のデータを受け取る側の実装もシンプルに組めそうです。
一方、KNNは、今の実装だとデータ配列を受け取って、それと同じサイズの異常度配列を返すので、オンラインで異常検知してやるには実装側でインプットのデータ配列をいい感じにずらしながらデータを投げ込んでやる必要があるし、計算もそこそこ重いです。

今後やりたいこと

Ruby・mruby周りで今後やりたいこと。

  • テストを書く
    今回はなるべく早く動かしたかったのでテストの実装をサボりました。Travis CIで自動テストするとこまではちゃんとやりたい。

  • 言語仕様を学ぶ
    下の本をちら見したらmrb_stateとかmrb_valueとか知らないことがいっぱい解説してあったので、ちゃんと読むと言語仕様を学ぶのに良さげな感じ。

eb.store.nikkei.com

オマケ:k近傍法(K-Nearest Neighbor :KNN)に基づく異常検知の理論

k近傍法とは一般的には多クラス分類のアルゴリズムですが、ちょっとした工夫で時系列データの異常検知にも応用することができます。
k近傍法を言葉で簡単に説明すると、「各点から最も近いデータへの距離を計算することで異常度を算出する手法」です。
もう少し詳しく解説していきます。
まず、1次元の時系列データを時間的に隣接したまとまりとして取り出します。これはスライド窓とも呼ばれ、下のようなイメージです。

f:id:hirotsuru314:20180401181356p:plain

この長さwの窓を左から右にずらしていくことで、1次元の時系列データをスライド窓の幅の次元数の列ベクトルの集合に変換することができます。
ここで列ベクトルとは空間上の点のようなものだとイメージして下さい。(正確には、ユークリッド空間の原点から空間内のどこか一点を結ぶ有向線分)列ベクトル同士には近い/遠い、すなわち距離の概念を考えることができます。k近傍法では、ある列ベクトルから距離が近いベクトルをk個取り出して、その距離の大きさをもとに異常度を算出します。
ここで、ベクトル間の「距離」の求め方と、「異常度」の算出方法には任意性があります。
今回の実装では、距離は典型的にはユークリッド距離を用いています。(マハラノビス距離などを使うこともできる)
異常度の計算には、k個の近傍距離の平均を用いました。

Terraformでインスタンスの停止ができない理由を考えたらInfrastructure as Codeへの理解が深まった話

こんにちは、筋肉系インフラエンジニア見習いのつるべーです。
私は今、GMOペパボ株式会社でペパボカレッジという第二新卒エンジニア向け研修を受けている真っ最中です!
今回のエントリーは、私が研修中に感じた素朴な疑問を会社のコミュニケーションツールに書いたら、そこから議論が広まって、最終的にはInfrastructure as Codeという重要な概念への理解を深めることができたよ、という話です。

Infrastructure as Codeって?

Infrastructure as Codeを一言で表すと「コードによりインフラの管理をすること」です。
コードで管理することのメリットとしては、

  • コードのバージョン管理ができる
  • 設定変更の適用前にプルリクエストベースで確認が行える
  • 設定の共有・再利用が容易である
  • オペレーションミスが防げる
  • インフラ構築の属人化が防げる

などが挙げられます。
現在、Infrastructure as Codeを実現するためのツールは、Terraform、Puppet、Ansibleなど数多く存在し、それぞれがコード管理をしたい対象のレイヤーが異なっていたりして、非常に複雑なため、その点については下記のブログが大変参考になります。

インフラ系技術の流れ - Gosuke Miyashita

サーバのプロビジョニングを「Orchestration・Configuration・Bootstrapping」という3つのレイヤーで分けて説明されている点がとても参考になりました。

問題提起

今回はタイトルにもあるようにTerraformというツールについての話です。(ツールに固執した話ではなく単に考えるきっかけがTerraformだった)
TerraformはHashiCorpが開発している「インフラの構築・変更を効率的に行うためのオーケストレーションツール」です。AWSにおけるCloudFormationのような存在です。

www.terraform.io

Terraform独自のテンプレートにインフラ構築に必要な各種リソース(インスタンスやネットワークなど)を定義し、適用のコマンドを実行すると、定義したインフラの「あるべき姿」を再現してくれます。私は、Terraformを使って実際のWebサービスを想定したインフラを構築する研修を受けていました。
Terraformでは、定義ファイルを書いてterraform applyとコマンドを叩くと定義した全インスタンスが立ち上がって、terraform destroyとコマンドを叩くと立ち上げた全インスタンスが削除されます。
ここで一つ疑問が湧きました。インスタンスの起動・削除はできるけど、インスタンスの停止は??
terraformコマンドのオプションを見てみると、(一部省略)

$ terraform --help
Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure
    env                Workspace management
    fmt                Rewrites config files to canonical format
    get                Download and install modules for the configuration
    graph              Create a visual graph of Terraform resources
    import             Import existing infrastructure into Terraform
    init               Initialize a Terraform working directory
    output             Read an output from a state file
    plan               Generate and show an execution plan
    providers          Prints a tree of the providers used in the configuration
    push               Upload this Terraform module to Atlas to run
    refresh            Update local state file against real resources
    show               Inspect Terraform state or plan
    taint              Manually mark a resource for recreation
    untaint            Manually unmark a resource as tainted
    validate           Validates the Terraform files
    version            Prints the Terraform version
    workspace          Workspace management

stopやpauseがないんですね。起動や削除はできるのに停止ができないのはなんでやねん!!ってなったわけです。
そこで社内のコミュニケーションツールで質問してみました。

つる「TerraformのCLIからインスタンスの停止ってできないんですか?」

すると・・・ペパボのハイパーエキセントリックボウイな先輩方が

「Terraformの役割をちゃんと説明できますか?」

インスタンスを停止したい理由がなぜかを考えてみては?」

「サーバのライフサイクルの観点から考えてみては?」

オライリーの『Infrastructure as Code』を読んだ方が・・」

「上のようなことがわかるとなぜTerraformで「インスタンスを停止する」操作をしないかが自分の言葉で言えるようになるかも」

などとありがたいコメントをいっぱいくれたわけです。これをきっかけに、私なりに色々考えた結果が今日のメインの話です。(素朴な疑問にこれだけ反応してくれる環境って最高ですよね?)

注意点

  • Terraform以外の他のツールがインスタンスの停止ができるのか?というところは知りません。したがって、議論のきっかけは汎用性に欠けるかもしれませんが、そこから得られる議論や考察には一定の汎用性があると思っています。

  • 後述の話はあくまで私の考察です。実際にTerraformが何かしらの信念をもって敢えて「インスタンスの停止を実装していない」のか、そこまで深い意味がないのかどうかは知りません。ただ、色々考えると、停止って別になくてもいいよねってなりました。(インスタンス停止が絶対ダメ!という話ではない)

  • 今回のサーバとインスタンスはほぼ同じ意味で使っています。

自分なりの考え

解釈が間違っていたり、他にも考えをお持ちの方はビシバシ指摘してください!

Terraformの役割は何か?

Terraformはインフラストラクチャの定義をコードで管理するオーケストレーションツールです。ここでいうインフラストラクチャは通常、相互に関連し合う様々なスタックから構成され、Terraformはこれらの複数のスタック構成を「ある状態」に収束させるためのツールであるともいえます。
つまり、Terraformの役割は、単体のサーバの管理ではなく、サーバーの集合体(クラスタ)を管理する役割です。これは「オーケストレーション」という言葉のそもそもの意味からも言えそうです。

オーケストレーションとは複雑なコンピュータシステム/ミドルウェア/サービスの配備/設定/管理の自動化を指す用語。(Wikipediaより)

とあるように「複雑な」システムの管理等が目的であるため、単体のリソースに着目するものではないと言えます。
このことから、Terraformでは「ひとつだけのサーバを停止する」ような操作を用意していないのかもしれません。じゃあ全台一気に停止するようなコマンドはあってもいいのでは?

サーバを停止したいのはなぜか?

「サーバを停止したいのはなぜか?」を考えると、それは「サーバの構成/設定を変更したいから」です。
Infrastructure as Codeの意義はインフラストラクチャの定義をコードで管理することで、「統一的な」管理ができる点にあります。そこに対して、サーバを停止して手作業で設定変更を行うなどといった管理されていない変更を許すと、統一的な管理が失われ、構成ドリフトやスノーフレークを招く恐れがあります。そのため、オートメーションの外からサーバに変更を加えることを認めてはなりません。これがTerraformからインスタンスの停止ができない理由の一つだと考えます。

サーバの変更管理モデルについて

ただし、インスタンスの停止ができないからといってオートメーションの外からの管理されていない変更を完全に排除することにはなりません。ここで、サーバの変更管理モデルにまで話を深めていくと、「Immutable Infrastructure」という考え方があります。これは、サーバの構成/設定を変更する際に、既に動いているサーバに対して変更を加えるのではなく、変更が加えられた全く新しいサーバを構築する手法です。これにより、オートメーションの外から加えられた変更を打ち消すことができ、構成ドリフトなどを防ぐことに非常に有効です。
このように昨今のインフラ、特に仮想化技術やクラウド技術が使われたインフラにおいては、「サーバのライフサイクルを短く保つこと」が求められています。こういった背景も、Terraformでインスタンスdestroyはできるがstopができない理由の一つかもしれないと考えました。

さいごに

今回のことを考えているうちにInfrastructure as Codeって本当におもしろいなーって思いました!ここに昨今のコンテナ化技術の議論が入っているとさらに奥が深くなりおもしろそうですね。私は今回の一連の議論からInfrastructure as Codeに非常に興味を持ったので、これからも勉強していきたいと思います。
あと、Twitterにも書いたのですが、

こんな成長できる環境に身を置けることが心から幸せです。以上、最後まで読んでいただきありがとうございました!

参考

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

「3分間ネットワーク基礎講座」を読んだ

ネットワークの勉強をするため「3分間ネットワーク基礎講座」という本を読みました。
私は2月からインフラエンジニアに転職しました。業務の中でネットワークのことを知らなすぎて危機感を感じたため、有名なマスタリングTCP/IP 入門編 第5版を読もうと試みたのですが、私にとっては難しすぎました。そこでもっと初心者寄りの本を探してこの本に行き着きました。

[改訂新版] 3分間ネットワーク基礎講座

[改訂新版] 3分間ネットワーク基礎講座

本の紹介と感想

本書を読んだ率直な感想は、「めっちゃくちゃわかりやすかった」です。ネットワークについてちゃんと学んだことがない人が最初に読む一冊としてはかなり良い選択だと思います。
本書は「3分間Networking」というWebサイトを元に書籍化したみたいです。
本書の特徴は、

  • 対話形式で読みやすい

  • OSI参照モデルを中心に広範囲のネットワークについてカバーしている

といった点が挙げられるかと思います。
対話形式である点は、正直好き嫌いがあるかと思うのですが、私は読みやすく感じました。もともとネットワークには堅苦しいイメージがあり、抵抗感があったのですが、難しいこともカジュアルにポイントを押さえて書いてあったので、頭に入りやすかったです。
内容としては、最初にネットワークの基礎について書いてあり、OSI参照モデルの話が出て、そこからOSI参照モデルの各レイヤーを下から順に丁寧に解説していく感じです。特にレイヤー1〜4に大部分のページが割かれており、レイヤー5以上は最後にちょろっと触れてあるだけでした。 本書を読むと、OSI参照モデルの全体像と各レイヤーの役割・要素技術の知識が得られます。 私はTCPとかIPアドレスとかふんわりとしか理解してなかったので、頭の中が整理されてちょうどよかったです。 これでマスタリングTCP/IP 入門編 第5版と戦えるようになっているはずだと信じて読み進めていきたいと思います!

読書ノート

私がポイントだと思ったことだけをまとめた読書ノートです。

1章 ネットワークの基礎知識

回線交換とパケット交換
  • データ通信には回線交換とパケット交換がある。コンピュータネットワークはパケット交換方式。
    データをパケットに分割して送るため回線を占有する時間が短く、回線を複数のコンピュータで共有できる。
ネットワークの構造
  • パケット交換機なしでケーブルの分岐でつながっている範囲のことをセグメントと呼ぶ。分岐させるためにハブという機器を使う。
    セグメントの範囲内にあるコンピュータはパケット交換機なしで直接データのやりとりができる。このようなネットワークの構造をマルチアクセスネットワークと呼ぶ。

  • 一方、専用線を用いて固定した相手としかデータのやりとりができないネットワークをポイントツーポイントネットワークと呼ぶ。

LANとWAN
  • LAN(Local Area Network)は地域的に狭い範囲で自身の責任で構築するネットワーク。

  • WAN(Wide Area Network)は離れた地域にあるLAN同士を電気通信事業者(NTTやKDDIなど)の通信ケーブルを借りてつないだネットワーク。
    世界規模で最大のWANがインターネット。

  • インターネット接続サービスを行うプロバイダはISP(Internet Service Provider)と呼ばれる。

OSI参照モデル
  • OSI参照モデル(Open Systems Interconnection Reference Model)はデータ通信の標準化を行うために作られたデータ通信全体の「段階と手順の設計図」。 OSI参照モデルではデータ通信を7つの段階に分けている。この段階のことを層(レイヤー)と呼ぶ。

  • レイヤーはそれぞれ独立している。すなわち、基本的にはレイヤーのプロトコル変更は他のレイヤーに影響しない。

  • 下のレイヤーは上のレイヤーのために働き、上のレイヤーは下のレイヤーのことに関知しない。

カプセル化
  • データとデータを送るために必要なものがまとまった状態をプロトコルデータユニット(PDU)と呼ぶ。 それぞれのレイヤーごとにPDUがあり、それらが順々にくっついて実際に送信するPDUができるイメージ。
    このようにデータに制御情報をくっつけてPDUを作り上げることをカプセル化と呼ぶ。

  • カプセル化で追加される制御情報は、データの前につくときはヘッダー、うしろにつくときはトレーラーと呼ぶ。

プロトコル
  • OSI参照モデルのレイヤーごとに、それぞれのレイヤーの役割のプロトコルが必要。

  • 上下のプロトコルをインターフェースでつなぐことでレイヤー7からレイヤー1までを一つのつながったプロトコル群と捉えることができる。基本的にはどのプロトコル群を使うかによって各レイヤーで使用するプロトコルが決まる。
    現在最も使われているのがインターネットで使われているTCP/IPプロトコル群である。

  • プロトコルは「データの中身を決める」「ヘッダーを決める」「やりとりの手順を決める」

TCP/IP モデル
  • TCP/IPIETF(the Internet Engineering Task Force)が制定している。
    IETFが制定する文章はRFC(Request For Comment)と呼ばれる。

2章 信号の伝送と衝突

レイヤー1の役割と概要
  • レイヤー1の役割は、ケーブルがつながっている機器への信号の伝達。

  • 信号が流れるパイプとなる通信媒体には有線と無線があり、優先には電気信号を使う銅線のUTP(Unshielded Twist Pari Code)と光信号を使う光ファイバーがある。

  • コンピュータとケーブルの仲介役であるインターフェースは、コンピュータが送りたいデータをケーブルに合った信号に変換してケーブルに流し、ケーブルから流れてきた信号をコンピュータで使うデータに変換する。

  • コンピュータで使われるインターフェースとして、LAN用のケーブルに接続するためのNIC(Network Interface Card)が一般的。

  • WANの場合の信号変換器をDCE(Data Circuit terminating Equipment:回線終端装置)と呼ぶ。

信号と衝突
  • インターフェースはビットを信号に、信号をビットに変換する機器である。信号にはアナログ信号とデジタル信号がある。

  • ビットは「0」か「1」、デジタル信号は「ON」か「OFF」であるため、デジタル信号はビットを表現しやすい。

  • 信号には減衰、ノイズ・干渉、衝突などの問題が発生する。

ハブ
  • ハブの機能1:複数の機器をつなげてネットワークを構築する機能。ハブにケーブルでつながっている機器は、同一のケーブルにつながっているのと同じ扱いになり、ハブにつながっている機器同士で信号のやりとりが可能になる。

  • ハブの機能2:ハブは減衰によって崩れた信号を元の形に増幅・成形する。増幅だけを行う機械としてリピーターというものがある。

  • ハブとハブをつなぐ接続をカスケード接続と呼ぶ。ハブをカスケード接続していけば大きなネットワークを作ることができる。

  • ハブは受信したポート以外のすべてのポートに受信した信号を送信する。これをフラッディング(Flooding)と呼ぶ。

  • 信号を送信すると衝突が起きるかもしれない範囲のことを衝突ドメインと呼ぶ。同じハブにつながっているコンピュータ同士は同時に信号を送信すると衝突が発生する可能性があるため、ハブでつながっている範囲は衝突ドメインにあることになる。(違うハブにつながっていてもハブ同士をカスケード接続していると衝突ドメインになる)「たまたま同じタイミング」で信号を送信する可能性を減らすためには衝突ドメインは小さくしなければならない。

レイヤー2の役割と概要
レイヤー2アドレスとイーサネット
  • アドレスはデータの送りかたによってユニキャスト、ブロードキャスト、マルチキャストの3種類存在する。
    ユニキャストは「1対1」の通信、ブロードキャストは「1対全」の全員宛の通信、マルチキャストは「1対多」の複数機器宛の通信。

  • それぞれの機器は最低1つ以上のユニキャストアドレスを持つ。ルーターのように複数のインターフェースを持つ機器は、インターフェースごとにユニキャストアドレスを持つ。

  • ユニキャストアドレスはユニークでなければならない。一方マルチキャストアドレスは「グループ番号」といった扱いであるため、同じアドレスを持つ機器が複数あってもよい。

  • イーサネットで使われるアドレスはMACアドレス(Media Access Control Address)と呼ばれるアドレスで、このアドレスはインターフェースにつけられた固定のアドレスである。

イーサネット
スイッチ
  • CSMA/CDは衝突を起こりにくくする仕組みであるため、衝突ドメインのコンピュータの台数が多い場合、衝突が起きて効率が悪くなる。これを防ぐために「信号が通る道を分ける」ための機器であるスイッチ(スイッチングハブ、L2スイッチなどとも呼ばれる)をハブの代わりに使用する。

  • 現在LANで使われているUTPや光ファイバーのケーブルは送信と受信の信号の通り道は分かれている。そのため衝突はケーブル上では発生せず、ハブで発生する。スイッチは「MACアドレスフィルタリング」と「バッファリング」で衝突を防ぐ。

  • スイッチはフレームを受信した際、送信元MACアドレスと受信したポートの対応をアドレステーブルという対応表の形で記憶する。これにより宛先MACアドレスに対応したポートからのみフレームを送信するのがMACアドレスフィルタリングである。
    MACアドレスフィルタリングにより別の宛先のフレームが同時にスイッチに届いても衝突が発生しなくなる。

3章 IPアドレッシング

レイヤー3の役割と概要
  • レイヤー3ではセグメント間でのデータのやりとりを行う。

  • ルーターはブロードキャストを中継しないので、ルーターを超えてブロードキャストは流れない。

インターネットプロトコル
  • レイヤー2のイーサネットではアドレスとしてMACアドレスを使ったが、MACアドレスに含まれているのはベンダーコードとベンダーがつけた番号だけで、「場所を特定できない」アドレスである。

  • レイヤー2で使用するアドレスは「物理アドレス」と呼ばれ、レイヤー3で使用するアドレスは「論理アドレス」と呼ばれる。違いはアドレスに位置情報が含まれているかいないか。

  • 「アドレッシング」と「ルーティング」によりインターネットワークを行うためのプロトコルとして、TCP/IPプロトコル群で使われるのがIP(Internet Protocol)

  • IPにはIP version4(IPv4)とIP version6(IPv6)があり、この二つに互換性はない。

  • データにIPヘッダーがついた状態のレイヤー3PDUはIPデータグラムと呼ばれる。

IPアドレス その1
  • IPアドレスネットワーク管理者がコンピュータに割り当てる。インタフェースが故障した場合、物理アドレスは変わるが論理アドレスは変わらない。
    MACアドレスはインターフェースに付属しているため、コンピュータどこにいても同じアドレスであるのに対して、論理アドレスはコンピュータの場所を変えるとアドレスも変わる。

  • IPアドレスにもユニキャスト・マルチキャスト・ブロードキャストの3種類のアドレスがある。

  • IPv4では32ビットで「ネットワークの番号」の「コンピュータの番号」を表す。8ビット毎の区切り(オクテット)を10進数にして表記される。

IPアドレス その2
  • 「ネットワークの番号」は接続されているすべてのネットワークでユニークである必要がある。これはICANN(The Internet Corporation for Assigned Name and Number)という組織が割り当てている。ICANNIPアドレスを実際に使うプロバイダーや企業に貸し出しているイメージ。

  • どのオクテットまでがネットワーク番号かでクラスに分けられる。ネットワーク番号の部分のビット数が少ないとそれだけ多くのコンピュータを所有する大きなネットワークになれる。

  • ICANNによりネットワーク番号が割り振られれば、コンピュータ番号(これをホスト番号と呼ぶ)はそのネットワーク管理者が決められる。

  • ホスト番号のビットがすべて0のアドレスはネットワークアドレスで、ネットワークそのものを示すアドレス。
    ホスト番号のビットがすべて1のアドレスはブロードキャストアドレスで、ネットワークに所属するすべてのホストを示す。

サブネッティング
  • IPアドレスは階層型のアドレスであり、大きなネットワークを小さなネットワークに分割できる。このように分割された小さなネットワークのことをサブネットワーク、またはサブネットと呼ぶ。

  • ホスト番号のビットを、サブネット番号とホスト番号に分割する。
    サブネットを使用する場合、IPアドレスはネットワーク番号、サブネット番号、ホスト番号で構成される。

  • サブネットを使用する場合はサブネットマスクと呼ばれるビット列をIPアドレスと一緒に表記する。ネットワーク番号・サブネット番号のビットをすべて1、ホスト番号を0にしたもの。サブネットを使用していなければクラスによってどこまでがネットワーク番号かわかる。

クラスレスアドレッシング
  • クラスフルアドレッシングは3つのクラスに分けるため、組織が使用するIPアドレスの個数がクラスにぴったりと当てはまらないと無駄が多くなる。そこで登場したのがクラスレスアドレッシング。

  • クラスレスアドレッシングでは必要なIPアドレスの個数からネットワーク番号を決める。例えばクラスCのネットワーク(192.168.32.0〜192.168.39.0など)をまとめて1つのネットワークとして運用する。

  • サブネットマスクと同様にネットワーク番号のビット数を表す値としてプレフィックス長がある。IPアドレスのうしろにスラッシュを書いてネットワーク番号のビット数を書く(例:192.168.32.0/21)。プレフィックス長はCIDR(Classless Inter-Domain Routing)表記とも呼ぶ。

DHCP
ARP
  • ARP(Address Resolution Protocol)は宛先IPアドレスに対応したMACアドレスを調べる。そのためにはIPアドレスMACアドレスの対応表であるARPテーブルを参照する。

  • ARPテーブルに宛先IPとMACアドレスの対応がない場合、ブロードキャストでネットワーク内の全コンピュータにARP要求が送信される。ARP要求を受け取ったコンピュータのうち、指定されたIPアドレスを持つコンピュータだけがARP応答を返す。ARP応答を受け取ったコンピュータはARPの結果をARPテーブルに載せる。

  • ARPテーブルの情報は一定時間で消去される。

DNS

4章 ルーティング

アドレスと経路
  • 宛先IPアドレスは最終的なデータの届け先を示すのに対し、宛先MACアドレスは同じネットワーク内での宛先(次の届け先)を特定する。宛先IPアドレスは最後まで変わらないが、宛先MACアドレスは変わる。

  • ルーターは宛先までの経路を示しているのではなく、次にどこへ送ればよいかだけ決定している。

  • ルーターがなければ別のネットワークへデータグラムを送ることはできない。
    コンピュータは「宛先が別のネットワークにある場合はルーターへ送信する」「宛先が同じネットワークにある場合は直接宛先へ送信する」というルールで動いている。

  • コンピューターが指定するルーターのことをデフォルトゲートウェイと呼ぶ。

ルーター
  • ルーターはネットワークの境界上にあり、複数のネットワーク同士をつなぎ、ルーティングにより次のルーターを指定して経路を作る。

  • ルーターは複数のインターフェースを持ち、それぞれ異なるIPアドレスを持つ。(複数のネットワークに所属している)

  • ルーティングとはデータグラムの宛先IPアドレスを元に、次に送信するルーターを決定すること。

  • ルーターはルーティングテーブルを持っている。

デフォルトゲートウェイ
ルーティング
  • ルーターは最適な経路を見つけるために他のネットワークへの経路をすべて知る必要がある。
    経路を知る方法としてルーターが自動で情報を交換し合い経路を知る動的ルーティングという方法がある。

  • 動的ルーティングのメリットは障害があった場合に、自動で新たな最適経路にルーティングテーブルを書き換えること。

  • 動的ルーティングのデメリットはルーター同士が情報を交換し合うため、その分の回線の転送を圧迫すること。さらに、最適な経路を計算するための処理能力も必要。

ルーティングプロトコル
  • ルーティングプロトコルとは、動的ルーティングにおいて、近接ルーターとの間でネットワークの情報を交換し合うためのルール。交換した情報を元にルーティングテーブルを変更する。
ICMP
  • IP以外のレイヤー3のプロトコルとしてICMP(Internet Control Message Protocol)がある。ネットワークの制御や管理に使用される。

  • 通常IPデータグラムのペイロードにはTCPセグメントかUDPセグメントが入るが、これらの代わりにICMPメッセージを入れて送る。

  • ICMPにはQueryメッセージとErrorメッセージがある。Queryは状態を調査するために使用されるメッセージで、Errorはエラーを通知するためのメッセージ。

  • pingやtracerouteはICMPを利用したコマンドである。

5章 コネクションとポート番号

レイヤー4の役割と概要
  • レイヤー4の役割のにはエラーで届かなかった場合にデータを送り直すエラー回復や、処理しきれないデータが溢れ出てしまうのを防ぐフロー制御などがある。

  • ポート番号を使って、どのアプリケーションにデータを届けるかを判別する。IPアドレスMACアドレスだけではアプリケーションを識別できない。

  • レイヤー4で用いられるプロトコルにはTCP(Transmission Control Protocol)とUDP(User Datagram Protocol)がある。主な役割は「エラー回復」「フロー制御」「アプリケーションの識別」

コネクションとセグメント
  • TCPではアプリケーション間のデータのやりとりを行う。このアプリケーション間のやりとりを行うデータの道のことをコネクションという。

  • TCPで作られる通信路は仮想的な通信路と呼ばれる。この仮想的な通信路を作り出すことをコネクションの確立という。

  • 大きいデータはMSS(Max Segment Size)に分割し、その先頭番号をシーケンス番号とする。

ポート番号
  • ポートとアプリケーションを接続する機能をソケットという。
ネットワークアドレス変換
NAPT
  • NAPT(Network Address Port Translation)の最大の特徴は、1つのグローバルIPアドレスで複数台が接続可能であること。NAPTではIPアドレスだけでなくポート番号も変換することによって複数台を識別可能にしている。

  • NAPTではNATテーブルにない変換はされないためセキュリティ面のメリットもある。一方、LAN内部に外部に公開したいサーバがある場合は、手動で変換を入力しておく(静的NAPT)

レイヤー5~7
  • レイヤー5~7はTCP/IPモデルではまとめて1つのプロトコルとして実装されていることが多い。

Prometheusをインストールして、サーバのメトリクスを取得してみる

こんにちは。インフラエンジニア見習いのつるべーです。
最近、オープンソースの監視ツールとして注目を集めているPrometheusのことが気になっています。サーバの監視ツールとしても大変優秀なようですが、時系列なデータを蓄積する時系列データベースとしての側面についても気になります。ということで、今回はCentOS7上にPrometheusをインストールして、監視対象のサーバのメトリクスを取得してみるところまでやってみます!

prometheus.io

Prometheusの概要

Prometheusは、Googleの出身者がGoogle社内の監視ツールである「Borgmon」の影響を受けて作った監視ツールです。
オープンソースであるため、GitHubにコードが公開されています。

github.com

Prometheusでは、監視を行うサーバが監視対象のサーバへメトリクスを取得しにいく「Pull型」のスタイルを採用しています。この際、監視対象のサーバにおいてデータ収集を行うコンポーネントを「exporter」と呼びます。exporterは既存の実装のものも多数存在し、自分で実装することも可能です。すなわち、取得できるデータはサーバの各種メトリクスに限らず、exporterを自作すれば様々な時系列データをPrometheusに溜めこむことができそうです。

動作環境

今回は、Vagrantで立てたCentOS7の仮想マシン上にPrometheusをインストールします。

Vagrantfileは下に載せている通りで、prom(192.168.10.11)がserver1(192.168.10.21)を監視するようにします。

Vagrant.configure("2") do |config|
  config.vm.box = "centos/7"
  config.vm.define :prom do |prom|
    prom.vm.hostname = "prom"
    prom.vm.network :private_network, ip:"192.168.10.11"
  end

  config.vm.define :server1 do |server|
    server.vm.hostname = "server1"
    server.vm.network :private_network, ip:"192.168.10.21"
  end
end

Prometheusのインストール

監視を行うサーバにPrometheusをインストールします。
※ 実行コマンドはすべてsudo権限で実行しています。

mkdir /usr/local/src/prometheus
cd /usr/local/src/prometheus
yum install -y wget
wget https://github.com/prometheus/prometheus/releases/download/v2.2.0/prometheus-2.2.0.linux-amd64.tar.gz
tar zxvf prometheus-2.2.0.linux-amd64.tar.gz
cd prometheus-2.2.0.linux-amd64

インストール完了後、Prometheusを起動します。

./prometheus --config.file=prometheus.yml

起動したのち、http://192.168.10.11:9090/graph にアクセスすると、下記のような画面が表示されると思います。

f:id:hirotsuru314:20180314010539p:plain

node_exporterインストール

次は、監視対象となるサーバにPrometheusのエージェントとなるnode_exporterをインストールしていきます。
node_exporterを利用すると、ハードウェアやOSに関連した様々な情報を簡単に取得することができます。

mkdir /usr/local/src/node_exporter
cd /usr/local/src/node_exporter
yum install -y wget
wget https://github.com/prometheus/node_exporter/releases/download/v0.16.0-rc.0/node_exporter-0.16.0-rc.0.linux-amd64.tar.gz
tar zxvf node_exporter-0.16.0-rc.0.linux-amd64.tar.gz
cd node_exporter-0.16.0-rc.0.linux-amd64

インストール完了後、下記コマンドにて起動します。

./node_exporter

起動したのち、http://192.168.10.21:9100/metrics にアクセスすると下記のようにメトリクスが表示されています。

f:id:hirotsuru314:20180314010553p:plain

このようにnode_exporterでは設定を行わずとも、デフォルトでホストのCPUやメモリ使用状況などさまざまなデータを取得できるようになっています。取得するデータは、起動時のオプションでカスタマイズすることもできるようです。
詳しくはこちらを見るとよさそうです。
これで監視対象サーバへのnode_exporterのインストールが終わり、あとは監視を行うPrometheus本体から監視対象サーバへデータを取得しにいくように設定をすればよさそうです。プル型の監視なので設定はもちろんPrometheus本体側に行います。
Prometheusを一旦停止して、/usr/local/src/prometheus/prometheus-2.2.0.linux-amd64/prometheus.ymlを下記のように書き換えます。

global:
  scrape_interval:     15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node'
    scrape_timeout: 10s
    static_configs:
      - targets: ['192.168.10.21:9100']

そして、再度Prometheusを起動し、http://192.168.10.11:9090/graph にアクセスします。 「Status」メニューの「Targets」を選択すると、データ取得対象一覧が表示され、先ほど設定した192.168.10.21:9100が表示されていると思います。

f:id:hirotsuru314:20180314010607p:plain

監視対象のサーバのメトリクスは「Graph」メニューで、「- insert metrix at cursor -」となっているプルダウンから任意のメトリクスを選択して「Execute」ボタンを押すと取得したデータ一覧がConsoleに出てきて、タブで「Graph」に切り替えると下のようにグラフが見ることができます。

f:id:hirotsuru314:20180314010733p:plain

おわりに

今回は、CentOS上にPrometheusをインストールする方法とnode_exporterを使って、サーバのメトリクスを取得するところまで書きました。実際には監視したメトリクスをもとにアラートを飛ばす機能やGrafanaというツールと連携してより美しいグラフを描画したりなどいろいろできます。また、exporterを自作すれば取得するデータの幅も広がりますし、工夫次第でいろいろできそうですね。
私個人としては、もともと時系列データの異常検知に興味を持っており、ライブラリを作ったりしていたため、Prometheusの時系列データベースに溜め込んだデータの異常検知などをやってみたいなーと思っています。
以上、今回は非常に単純な内容でしたが、今後はPrometheusの応用編も書けるといいなーって思っています!

消防士を辞めて1年2ヶ月…GMOペパボのインフラエンジニアになった

2018年2月1日にGMOペパボ株式会社に入社しました!
消防士を辞めてエンジニアに転職してからの1年2ヶ月は福岡のシステム開発会社で機械学習などのデータサイエンスの分野に取り組んでいましたが、ペパボにはインフラエンジニアとして入社しました。今回の記事は、いわゆる転職エントリというやつです!転職の理由などを振り返っていきます!
消防士からエンジニアへの転職については下の記事にまとめてます。

www.hirotsuru.com

なぜインフラエンジニアになったのか

私はこれまでデータサイエンスの分野に取り組んできたため、「機械学習エンジニア」や「データサイエンティスト」といった道もあったのですが、インフラエンジニアになりました。その理由を書いていきます。
データサイエンスの分野は、機械学習アルゴリズムへの理解や、それらをプログラムに落とす力はもちろんのこと、それに加えて対象となるドメイン(事業領域)の知識が重要となります。私はこのドメインが自分の興味の領域と一致していると、データサイエンスをやっていて一番楽しいと感じることができると気づきました。逆にあまり興味がないデータを扱うのはそんなにおもしろくないなとも思いました。そう感じて以来ずっと、自分が興味があって、データサイエンスの活用が有効である領域を探していました。
そんなときにたまたま参加したイベントでペパボの@udzuraさんの発表を聞き、インフラに興味を持ちました。ITインフラの現場においては、サーバのCPUやメモリ等の各種リソースの使用量、ネットワークトラフィック、I/O要求といった時系列データが時々刻々と蓄積されていて、データサイエンスの応用の幅が広いと感じました。(その時のスライドは下のリンク)

コンテナたちを計測すること ~ ロリポップ!マネージドクラウドの裏側 ~ /wip-how-to-get-container-metrics // Speaker Deck

これをきっかけにインフラに興味を持ち、インフラエンジニアへのジョブチェンジを決めました。きっかけはデータサイエンスの活用の場としてのインフラでしたが、今ではデータサイエンス抜きにしても、純粋にインフラに興味を持っており、Linuxカーネルやネットワークまわりなど学びたいことが増えました。

なぜペパボに入ったのか

上でも述べましたが、ペパボの方の発表がきっかけでインフラに興味を持ちました。さらにペパボにはペパボ研究所という事業を差別化するための研究開発に取り組む組織があり、そこの研究実績を見ていくと、ITインフラの抱える課題をデータサイエンスの力で解決していこうとする事例をいくつか見つけて、ひたすら興味が湧いてきました。

特徴量抽出と変化点検出に基づくWebサーバの高集積マルチテナント方式におけるリソースの自律制御アーキテクチャ / 2017 iot36 // Speaker Deck

アクセス頻度予測に基づく仮想サーバの計画的オートスケーリング/Scheduled Autoscaling of Virtual Servers by Access Frequency Prediction // Speaker Deck

それからずっとペパボのことが気になっていて、ネットで情報を追いかけていました。そんな矢先、ペパボカレッジの応募を見て、これしかない!と思いました。

ペパボカレッジ

ペパボカレッジとは第二新卒エンジニア向け研修のことで、ペパボカレッジで採用されると、中途採用でもみっちり研修を受けられます。私はエンジニア歴も浅いし、そもそもインフラの経験がなかったため、このペパボカレッジの応募はまたとないチャンスだと感じました。
ペパボカレッジについては詳しく知りたい方は下の記事を見てください!

www.wantedly.com

私はペパボカレッジ6期生として入社して、3月1日から東京で研修を受けている真っ最中です。素晴らしい講師陣と熱い同期に恵まれて、やっていくぞ!という気持ちが高まりまくっています!
インフラエンジニアのペパボカレッジは今回が初めてなので、4月上旬に研修が終わった後には、全体のまとめを書きたいと思います!多分書きます。

転職するときにやっておいてよかったこと

一番やっておいてよかったことは、技術的なアウトプットなのですが、やり方も工夫すべきかなと思います。例えば、私の場合は、「ペパボに入りたい」と思ったその日に、応募のエントリーフォームを見ました。

f:id:hirotsuru314:20180304235837p:plain

f:id:hirotsuru314:20180304235849p:plain

私はこれを見て、ポートフォリオを作りましたし、GitHubSlideShare(Speaker Deck)の体裁を整えました。まぁこれが受かった理由かはわかりませんが、少なくとも自分自身が自信を持って面接に望めるようになると思うので、その会社がどういったものを見るのか(何を提出するのか)は見ておいて損はないでしょう。

1ヶ月働いて見て

もともとネットですごいなーって見ていた方々と近くで働くのはすごく刺激的です!周りに尊敬するすごいエンジニアがいるというのはエンジニアにとっては何にも変えがたい福利厚生だと思います。
またペパボで1ヶ月働いていいなーと感じたのは、誰かが何かに挑戦しようとしているときに、皆が「やばいじゃん」とか「ええやん」とかすごくポジティブな言葉をかけていて鼓舞していることです。これは見ていて本当に気持ちがいいです。こういう雰囲気だと自分の意見を言いやすくなるし、それで議論が活発になると会社全体としてもいい効果がありそうだなーと思いました。
あと、飲み会に参加したときに印象的だったのが、その場にいない社員のことを「あの人のこういうところはすごい!」とか皆で絶賛していたことです。そういうの最高ですよね。いろんな意味でポジティブな会社だなーって思いました。

これからやりたいこと

1. 得意な(好きな)分野をみつけたい

インフラといっても非常に広い分野なので、その中でも自分が特に好き分野を見つけて、それを得意な分野にしていきたいです。さらに、分野を見つけるだけにとどまらず、OSSの開発をしたり、その成果をイベント登壇やブログを通じてアウトプットしていきたいです。

2. 「比較から学ぶ」をやりたい

エンジニアになってからこれまでの1年ちょいを振り返ると、目の前のことを必死で勉強していただけだったので、知識の幅が狭すぎるなと感じました。そこで最近は、何かの勉強をする上で「比較から学ぶ」というのが大事だなーって思っています。 具体的には以下の2つのアプローチがあると思います。

① 過去との「比較から学ぶ」

これは、「歴史から学ぶ」と言い換えてもいいかもしれませんね。私のように最近プログラミングを始めたばかりの人は過去の技術に対する知識が乏しく、それが現在の技術の理解度にも影響を与えているのではないかと思いました。
その技術は「なぜ生まれたのか」「何の問題を解決したのか」「生まれてからどういう進化をたどったのか」などを知ることは大事だと思ったので、過去の技術を知る努力もしようと思います。

② 他の技術との「比較から学ぶ」

これは同レイヤーの他の技術を学ぶこと、例えば関数型言語を勉強することで、オブジェクト指向への理解が深まるといった類のことを指しています。自分の専門としたい分野に留まらず、視野を広げると、結果として自分の分野にも好影響を及ぼすのでは、と思ってきたので、意識的にやってみたいと思います。

3. ベンチプレス150kg挙げたい

これはそのままですね。せっかく消防士時代に鍛えた体にもう一度鞭を打って、バルクアップしたいと思います。その上で明確な目標がほしいと思ったので、1番好きなトレーニングであるベンチプレスを150kg挙げるという目標を掲げました!

以上、これからはインフラエンジニアとして自分の分野を開拓し、バリバリ活躍できるよう頑張っていくので、これからもよろしくお願いします!!

シリコンバレーのIT企業に行ってきた!

1月の末に約1週間、サンフランシスコ・シリコンバレーに行ってきました!エンジニアになってからすごく興味を持っていたシリコンバレーの有名IT企業を回ってきたので、写真を中心にご紹介します!

Facebook

有名ないいねの看板

f:id:hirotsuru314:20180224210753j:plain  

会社の中は広すぎて、雰囲気も街みたいでした!

f:id:hirotsuru314:20180224211022j:plain

f:id:hirotsuru314:20180224211037j:plain

食堂

f:id:hirotsuru314:20180224211323j:plain

会社の中にゲーセンがあった。 食堂もゲーセンも全部無料でした!すごい福利厚生・・

f:id:hirotsuru314:20180224211350j:plain

Google

オフィスの中にいっぱい人形がいるスポットを発見!

f:id:hirotsuru314:20180224211719j:plain

アンドロイドのマスコットのやつ。でかっっ!

f:id:hirotsuru314:20180224211816j:plain

KitKatバージョン??

f:id:hirotsuru314:20180224212306j:plain

  Googleカラーの自転車。会社の敷地が広すぎるから社員はこれで移動してるっぽい。

f:id:hirotsuru314:20180224211857j:plain

Googleのグッズが買えるショップ。最近できたっぽい。

f:id:hirotsuru314:20180224212117j:plain

f:id:hirotsuru314:20180224212130j:plain

Apple

Apple本社

f:id:hirotsuru314:20180224212726j:plain

一般の人はどこにでもありそうなアップルストアに入れるだけでした。

f:id:hirotsuru314:20180224212739j:plain

f:id:hirotsuru314:20180224212751j:plain

おまけ(サンフランシスコ市内)

サンフランシスコとシリコンバレーは車で1時間弱ぐらいの距離です。サンフランシスコ市内も観光しました。

移動手段はケーブルカー!

f:id:hirotsuru314:20180224214204j:plain

サンフランシスコを代表する観光名所であるフィッシャーマンズワーフのカニの看板

f:id:hirotsuru314:20180224214222j:plain

フィッシャーマンズワーフにはおいしい食べ物がいっぱいあった!
クラムチャウダー

f:id:hirotsuru314:20180224214309j:plain

カニがいっぱい入ったパン

f:id:hirotsuru314:20180224214334j:plain

感想

今回はシリコンバレーの中でも有名な大企業を回りましたが、どこも敷地が超広いし、スケールが大きかったです。建物も日本のオフィス街みたいに高層ビルなどは全くなく、2・3階建の横に広い建物が立っていました。そもそもがアメリカと日本で国土の広さが全然違うので、こういった違いが生まれるのかなーなんて思ってました。
あとは、働く人たちがすごく自由に働いているように感じました。Facebookとか、カフェとかゲーセンとか全部タダで、日中でも常にカフェとかに人がいっぱいいるので「この人たちいつ働いているんだろう?」って感じました。でも、おそらくオンオフの切り替えや時間管理がうまかったりして、そんな人たちでも凄まじく生産性が高かったりするんだろうなー。
シリコンバレーはすごく刺激的(特にエンジニアにとって)な街なので、みなさんもぜひ機会があれば行ってみてください!