Fire Engine

消防士→ITエンジニア→研究者

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

blog.tsurubee.tech

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

私はこれまでデータサイエンスの分野に取り組んできたため、「機械学習エンジニア」や「データサイエンティスト」といった道もあったのですが、インフラエンジニアになりました。その理由を書いていきます。
データサイエンスの分野は、機械学習アルゴリズムへの理解や、それらをプログラムに落とす力はもちろんのこと、それに加えて対象となるドメイン(事業領域)の知識が重要となります。私はこのドメインが自分の興味の領域と一致していると、データサイエンスをやっていて一番楽しいと感じることができると気づきました。逆にあまり興味がないデータを扱うのはそんなにおもしろくないなとも思いました。そう感じて以来ずっと、自分が興味があって、データサイエンスの活用が有効である領域を探していました。
そんなときにたまたま参加したイベントでペパボの@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とか、カフェとかゲーセンとか全部タダで、日中でも常にカフェとかに人がいっぱいいるので「この人たちいつ働いているんだろう?」って感じました。でも、おそらくオンオフの切り替えや時間管理がうまかったりして、そんな人たちでも凄まじく生産性が高かったりするんだろうなー。
シリコンバレーはすごく刺激的(特にエンジニアにとって)な街なので、みなさんもぜひ機会があれば行ってみてください!

Pythonで学ぶUnixプロセスの基礎

 先日、自身が主催するPyFukuokaというイベントにて「Pythonで学ぶUnixプロセスの基礎」というタイトルの発表をしました。スライドはこちらです。

speakerdeck.com

 内容としては「なるほどUnixプロセス」という本を参考にしています。本書は、Unixの基礎から、ファイルディスクリプタの話や、fork(2)を使って子プロセスを生成する方法など、非常に内容が濃く、超オススメです。本の中ではRubyを使って解説されていますが、私の発表では、この本の一部をPythonを使ってまとめました。
 以下、スライドの内容に沿って書いていきます。

動作環境

プロセスにはIDがある

プロセスはプロセスIDという値を持っています。プロセスIDはプロセスの中身とは関連づいていない単に連番になった数値のラベルです。
それではPythonインタプリタを起動して、プロセスに振られたIDを確認してみます。
(補足:Pythonでは「os」という標準ライブラリを利用することで、OS関連の機能を利用することができます。 )

$ python
>>> import os
>>> os.getpid()
1229

「1229」という数値が返ってきました。ターミナルの別ウィンドウでpsコマンドをたたくと、

$ ps -p 1229
  PID TTY           TIME CMD
 1229 ttys000    0:00.06 python

確かにPIDが1229でPythonのプロセス立ち上がっていることがわかります。(PIDはプロセスIDのこと)

プロセスには親がいる

すべてのプロセスには親となるプロセス(親プロセス)がいます。たいていの場合、親プロセスはそのプロセスを起動したプロセスとなります。
Pythonインタプリタを起動して、親プロセスのIDを確認してみます。

$ python
>>> import os
>>> os.getppid()
1165

親プロセスを確認する関数はgetppidで、pが一つ増えていることに注意してください。(parentのp)
Pythonプロセスの親はそれを起動しているbashプロセスになります。

プロセスは子プロセスを作れる

fork(2)システムコールを使うと、実行中のプロセスから新しいプロセスを生成できます。システムコールは、OSの機能を呼び出すための仕組みのことです。
以下、fork(2)システムコールの特徴を挙げます。

  • fork(2)を呼ぶ側のプロセスは「親プロセス」、生成されるプロセスは「子プロセス」となる。
  • 子プロセスは、親プロセスで使われているすべてのメモリのコピーと、親プロセスが開いているファイルディスクリプタを引き継ぐ。
  • 子プロセスがコピーしたメモリは、親プロセス側に影響を与えることなく自由に変更ができる。

それでは、fork(2)を使って、プロセスを生成してみましょう。Pythonからfork(2)を呼ぶためにもosライブラリを利用します。

import os

if os.fork():
    print("Here in the if block.")
else:
    print("Here in the else block.")

上記のプログラムに「fork.py」というファイル名をつけて実行すると、

$ python fork.py
Here in the if block.
Here in the else block.

if句の中もelse句の中もprint文が実行されており、すごく不思議な現象です。
なにが起きてるのか追ってみましょう。

forkの挙動を追ってみる

forkの挙動を追うためにif句・else句それぞれで、以下の2点を調べます。

  1. プロセスIDはどうなっているか
  2. fork関数の返値はどうなっているか
import os

print("---- before fork ----")
print("pid: {0}".format(os.getpid()))
ret = os.fork()

if ret:
    print("----- if block ------")
    print("pid: {0}".format(os.getpid()))
    print("return value: {0}".format(ret))
else:
    print("---- else block -----")
    print("pid: {0}".format(os.getpid()))
    print("return value: {0}".format(ret))

上記のプログラムに「fork_detail.py」というファイル名をつけて実行すると、下のような結果になります。

$ python fork_detail.py
---- before fork ----
pid: 1103
----- if block ------
pid: 1103
return value: 1104
---- else block -----
pid: 1104
return value: 0

まず、プロセスIDについて見てみると、forkする前(プロセスを生成する前)とif句の中が同じプロセスIDで、else句の中はif句に1足したプロセスIDを持っていることがわかります。これは、if句は親プロセス(プロセスID:1103)によって実行されており、else句はfork関数によって生成された子プロセス(プロセスID:1104)によって実行されていることを意味しています。
次に、fork関数の返値を見てみると、親プロセス側には「生成した子プロセスのID」を返し、子プロセス側には「0」を返しています。Pythonの条件式では、正の整数値はTrue、0はFalseと評価されるため、この返値によって、親プロセスはif句の中、子プロセスはfalse句の中と実行内容を分けて記述することができます。

プロセスは通信できる

複数のプロセス間でデータをやりとりするための仕組みのことをプロセス間通信(IPC: Inter Process Communication)と呼びます。 IPCには様々な手法がありますが、今回は比較的単純な「パイプ」を使った方法を紹介します。
パイプは親子関係にあるプロセス間の単方向の通信を実現します。
まず、パイプの概略図を示します。(参考リンク

f:id:hirotsuru314:20171224144448p:plain

forkによって生成された子プロセスは、親プロセスが開いているファイルディスクリプタを引き継ぎます。ファイルディスクリプタとは、OSがカーネルのレイヤーで用意している抽象化の仕組みです。Unixの世界ではファイルシステム上のファイルだけでなく、デバイス、ソケット、パイプなどもファイルとして扱われるため、ファイルディスクリプタが割り振られます。
プロセスがパイプを作ったあとでforkを呼び出した場合、生成された子プロセスは同じパイプを読み書きできるため、親子間でデータを渡すことができます。

import os
reader, writer = os.pipe()
if os.fork():
    os.close(reader)
    write_pipe = os.fdopen(writer, 'w')
    write_pipe.write('Hello child!')
    write_pipe.close()
else:
    os.close(writer)
    read_pipe = os.fdopen(reader, 'r')
    message= read_pipe.readline()
    read_pipe.close()
    print(message)

上記のプログラムに「pipe.py」というファイル名をつけて実行すると、

$ python pipe.py
Hello child!

親から子にメッセージを渡せていることがわかります。

まとめ

プロセスは、IDがあって、親がいて、子を作れて、通信ができます。そして、その様子をPythonから確認できます。今回紹介した内容は、特にPythonである必要はありません。しかし、Pythonなどの高級言語を使って、OS周りの理解を深めることは、学び方の一つのアプローチとして有効だと私は考えます。
なるほどUnixプロセス」という本には今回の内容以外にも様々なプロセスの特徴について解説しています。 下記がその例です。

  • 孤児プロセス
  • ゾンビプロセス
  • デーモンプロセス
  • ソケット通信

この辺りに興味がある方はぜひ本を読まれることをオススメします!

消防士からエンジニアに転職して1年が経った

 消防士として働いていた私がゼロからプログラミングを始めて、ITエンジニアに転職してから1年が経ちました。今回は、1年間エンジニアとして働いた今の率直な思いと、1年の振り返りをしていこうと思います。

転職してどうだったか

 私はエンジニアという仕事は自分に合っているし、転職して本当によかったと思っています。しかしそれは、すべての人に「ITエンジニアっていいよ!」って勧められるというわけではなく、当たり前のことですが、合う・合わないがあると思います。
 私が思うエンジニアの仕事が合う人の特徴は「学ぶことが好きだ」ということに尽きると思っています。正直、エンジニアとして1年間働いて、未経験でもそこそこいけるなっという感覚の方が強かったです。それは、目の前の業務にだけ集中し、業務で必要な技術だけを追えばなんとか仕事はこなせるようになるからです。しかし、そのような場合は大抵、業務で使うフレームワークやライブラリの使い方の暗記ゲームをしているだけで、自分自身にはそんなに力がついてない状態だと思います。(私も最初の半年は完全にこの状態でした。。)
 私は目指すべきゴールを、所属している組織で活躍することではなく、エンジニアとしての市場価値を高めるところに置くようにしました。技術が高く、市場価値が高い状態がエンジニアとしての安定なんだと思います。

エンジニアとして大切にしていること

 私がエンジニアとして働く上でテーマに掲げているのが「継続的なインプットとアウトプット」です。出社前や退社後に毎日勉強し、定期的にイベントへの登壇やブログへのアウトプットを心がけています。インプットとアウトプットはどちらも大切ですが、両者のバランスに悩むことはしばしばあります。その両者のバランスについて、ある方から「アウトプットするのはインプットが溢れ出たとき」という話を聞きました。なるほど、確かにインプットして新しいことを覚えると、人に話したくなりますもんね。私はこれからはとにかくインプットしまくって、それが溢れ出るように、開発・登壇・ブログなどへアウトプットできるようにしたいと思います。意識の上で重きを置くのはアウトプットではなくインプットの量です。

1年間でやったことのまとめ

ライブラリ開発

Banpeiという異常検知ライブラリを作りました。特異スペクトル変換という手法を用いて時系列データの変化点検知が行えるのが特徴です。

github.com

f:id:hirotsuru314:20171115011620p:plain

<デモ動画>


特異スペクトル変換による傾きの変化点検知

<関連記事>
異常検知ライブラリを作ってみた - Fire Engine
特異スペクトル変換法による時系列データの異常検知(Python) - Fire Engine

イベント登壇

Date Event Slide
2017/11/18 九州 Data Scientist MeetUp 2017 異常検知ライブラリを作った話
2017/10/26 PyFukuoka #2 Pythonによるパッケージ開発〜異常検知パッケージをつくってみた〜  
2017/09/20 プログラマのための数学勉強会@福岡 #6 異常検知の基礎と実践 〜正規分布による異常検知〜
2017/09/01 PyFukuoka #1 Pythonによる可視化まわりの話
2017/06/17 第3回データサイエンスLT&勉強会 in LINE福岡! 時系列データ分析とPython〜カルマンフィルタによる状態推定〜
2017/01/30 Oisix機械学習勉強会 トピックモデルでテキストをクラスタリングしてみた
2017/01/15 第2回データサイエンスLT&勉強会 ニューラルネットワークでニュース記事を自動分類してみた

コミュニティ活動

PyFukuokaというコミュニティを立ち上げ、福岡でPythonを盛り上げるために活動中です。定期的にLTイベントを開催し、私も登壇してます!

f:id:hirotsuru314:20171126223507p:plain

正直どれをとっても納得する部分はないですが、こうやって過去の活動をまとめるのは自分の現在の状況を顧みるいい機会になりそうです。

これからやりたいこと

 私はこれまでの1年間は主に機械学習統計学といったデータサイエンスの分野に取り組んできました。その中で感じたことは、データサイエンスは課題解決の強力なツールの一つだということです。私はデータサイエンスに主軸を置くのではなく、興味のある分野の仕事をしながら、そこで出てきた課題をデータサイエンスの力で解決することがおもしろいと思っています。
 現在一番興味がある分野が、これまで全くといっていいほど触れてこなかったインフラです。アプリケーション側よりもそれらを支えるインフラ側に興味がシフトしてきました。また、ITインフラの現場においても、サーバのCPUやメモリ等の各種リソースの使用量、ネットワークトラフィック、I/O要求といった時系列データが時々刻々と蓄積されており、データサイエンスの応用の幅は広いと思います。中でも、システム監視の自動化に興味があります。(Banpeiを使って挑戦してみたい)データサイエンス抜きに考えても、ネットワークやOSまわりにはかなり興味が惹かれています。将来的にはインフラとデータサイエンスの二つの知識・技術をもったエンジニアになりたいと考え始めました。

さいごに

 本当の天才達からすると、多くの人間は地頭の差なんて誤差の範囲であり、一番大事なのはマインドの部分だと思います。さいごに、未熟者の私のマインドを常に押し上げてくれた方々の記事を紹介させていただきます。どの記事も本当に素晴らしく俄然モチベーションがあがります。