インフラエンジニアの教科書読んだ

インフラエンジニアの教科書

読んだ。業務でアプリケーション開発をしているだけでは分からなかった領域を知れてよかった。以下のようなトピックをざっくりと解説しているが、ちゃんと頭の中に収めるには他の本を読んだりやれる領域は実際に手を動かしてみる必要がありそう。

サーバ

• タワー型・ラック型などのサーバの種類
• SATA・SAS・SSD等ストレージの種類
• 仮想化技術・ハイパーバイザなど
• RAIDで行う冗長化とパフォーマンス向上の戦略

ネットワーク

• ルータの役割
• L2/L3スイッチ
• L4/L7スイッチ（LB）
• ネットワーク構成の構造（front/back2層・3階層構造・ネットワークファブリック）
• OSI参照モデル

ストレージ

• ローカルストレージ・外部ストレージ・ホットスペアなど
• 外部ストレージを利用したディスクI/O性能の向上
• シンプロビジョニング（容量の仮想化）

DC

• DCの選定（拡張性・地理的要因・空調など）
• ネットワーク機器の配置・エアフローなど

障害対応

• ボトルネックの特定
• ファームウェアの更新
• ハードウェアの保守など

大規模インフラ

• 資材調達
• CDN
• DSR構成による負荷分散（L4スイッチを上位スイッチに直接接続することで捌けるリクエスト量を増やし、ネットワーク構成の自由度を上げる）

広範囲な領域をざっくりと説明しているだけなので、ひとつひとつの解説が薄い感は否めない。インフラエンジニアのお仕事案内としてはよいかもしれないけど、業務レベルとなると全く太刀打ち出来ないという認識を持ってもう少し詳しい解説をしている書籍を読む必要がある。今度はネットワーク構成についてや高可用性が求められる場合におけるアプリケーションのシステム構成、要求性能の算出からハードウェアを選定する技術などを学びたい。

ある光

実家の愛犬、ごんたくんが旅立ってしまった。

12月の頭から調子が悪くなり始めて、1/20の未明にあっさり逝ってしまった。心臓病だった。13歳と3ヶ月だった。

12月に調子が悪いという報告を聞いた日、偶然なのかお告げなのか分からないけど、僕はたまたまごんたくんの夢を見ていて、ちょっと嫌な予感がしていたところに本当に知らせがきてびっくりした。会えるのが最後になるかもしれないと思い年始に帰省したのだけれど、痩せてはいたものの思ったより元気そうだったので一安心していた矢先だった。「遺影撮っておかなきゃ」なんて冗談交じりに言いながらカメラを向けていたけど、まさかそれから3週間で本当に死んでしまうなんて正直思っていなくて、今も現実感がなかったりする。年末年始は仕事関連でも色々あったので悩んでいたけれど、帰省しておいて本当によかった。最後に、頭を撫で、ジャーキーをあげて、 一緒に散歩することもできた。

いつも母が仕事から帰ると小屋から出てきて喜ぶのだけど、それが出てこなくなって、2日後のことだったらしい。その日は夜中まで母親についてもらっていて、翌朝様子を見てみると、眠るように死んでいたそうだ。最後まで大好きな母に撫でてもらって、ごんたくんは幸せだったと信じたい。

誰かを噛んで怪我させたことなんで一度もないし、初対面の人でも決して吠えたりしない優しい犬だった。いつも家族に対して愛想よく振る舞って、僕と散歩するときは飛び跳ねて喜んだりしていた。芸は待てとお手と伏せくらいしかできなかったけど、僕はそんなごんたくんが好きだった。

元々は、おばあちゃんの家で飼われていた犬に子どもが産まれてしまったという田舎ではよくある話で、引き取り手が必要になって我が家にやってきた仔犬だった。僕が13歳のときだ。妹が大事そうに抱えていたその雑種の仔犬は、突然別の場所に連れて来られて不安そうな表情をしていたのを、よく憶えている。寒い冬の日の夕方、一緒に歩いた道すがら、ごんたくんが立ち止まって、僕も立ち止まって、遠州のからっ風が吹いた時、空は美しい赤で、ああ、僕らは心が通じていると感じた（犬を飼う人のいくらかは分かってくれると思う）こと、多感な時期に色々悩んで、ナンバーガールだとかフィッシュマンズなんかを聞きながら何も言わない少年の側にいつまでもいてくれたこと、上京してからあまり帰省したかったけど、ごんたくんは僕のことをちゃんと覚えていて、帰省する度に喜んでくれたこと。そんな思い出の断片が、僕の身体の中で跳ねっ返る。

1/19は妹の20歳の誕生日で、もしかしたらごんたくんは妹の成人を見届けるまで頑張ってくれたのかもしれない。

夜になるとごんたくんを思い出して、泣いてしまう。こうして文章にすると、僕は自分でもびっくりするくらいごんたくんが好きだったということ、ごんたくんと過ごした日々がいかに素晴らしいものだったかということに、改めて気付かされる。

ごんたくん、大好きだよ。今までありがとう。

2014年振り返り

少し早いけど、2014年の振り返り。

濃い1年だった。エンジニアとして多くのことを学び、多くのことが今だ学べずに残してしまっている。この1年を誰に感謝するかと問われれば、それはJavaScriptだろう。2月から4月まではサーバ・クライアントどちらもJavaScriptの新規サービスの開発をする機会があり、それが自身にとって得難い経験となった。今まではjQueryでDOM操作をする程度の表層でのみ利用していて気がついていなかったメソッドの意味や、曖昧だった言語の仕様、ソフトウェアに対する要求について考えることができた。必然的にモダンなJavaScript界隈の話を見聞きすることが多くなり、新しい技術やトレンドを追い出すようになった。また、チーム内で教える立場になったこともあり、曖昧な認識では説明できないことが増えた。聞かれたことを夜な夜な学んで翌日しれっと話す、といったことも何度かあったが、未だ充分な役割は果たせていないように思える。

Keep

• いわゆるMEANスタックであるとか、WebScoket、WebComponentsなどについて学んだ。モダンなフロントエンド開発や技術については今後も継続して色々挑戦していきたい。NodeやMongoなども。

• 自分が触ったことのない言語に挑戦した（主にGo, Swift, Rubyなど）。使いこなすレベルにまで至っているものは少ないが、手を動かしたり言語仕様について学んだりすることができた。

• 多少のアウトプットはできた。何度か発信することができたように思う。同人誌にSocket.IOの記事を書いたりした。

• 外のライブラリに機能追加pull requestを投げた。Angular.jsのプラグインになかった機能を自分で追加して後日pull request投げた。「機能はOK。ちょっとテスト足りないから追加で書いといたわ」と言われたのが切ない。

Problem

• 全体的に、テストを書いた方がいい機会で書けなかった。よくある時間がないとかいうアレだったのだけれど、テスト書いておけばエンバグして手戻り、みたいな作業減るよなーという場面を作ってしまった。

• インフラに関する知識が足りない。ネットワークやシステム構成の話の基本的な部分から、各種のミドルウェアに対する理解だったり。あとAWSとか全然ついていけてない。

• 新しい言語やフレームワークを学んでも自分で何か作れるところまでいかなかった。また、設計やデザインパターンについてもっと理解を深めたいが。

• 依然としてアウトプットが少ない

• 英語が思ったより学べなかった。夏くらいまでは毎日Podcast聞いたりしていたけど、最近は全く手がついていない。

Try

• テストが当たり前の状況にする。そのためにRailsでRSpecを使って、テストの導入からテスト駆動な開発まで自分でやってみる。また、jsでもテストが当たり前で書けるように書ける部分は原則書くようにする。

• マスタリングTCP/IPをひと通り読む。AWSで1つのアプリケーションを色々なミドルウェアを使って動かしてみる。herokuとかに色々任せきりにしない。nginx, (apache), mysql, redisなどを１人で色々設定してみる。

• 自分でライブラリを作って公開してみる。デザパタ本を読みなおしたりDDD本を読んだりしてブログにまとめる。

• 月1で記事を書く。また、月1で振り返りをして、軌道修正を行う。

• 課題を課すためにも、できる限り毎日DUOとかやる。

今年読んだ本

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

iOSアプリエンジニア養成読本[クリエイティブな開発のための技術力/デザイン力/マインドを養う! ] (Software Design plus)

開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

白と黒のとびら: オートマトンと形式言語をめぐる冒険

Swift離陸ガイド

Swiftではじめる iPhoneアプリ開発の教科書 【iOS 8&Xcode 6対応】

• 読んでる・途中で止まってる本

シングルページWebアプリケーション ―Node.js、MongoDBを活用したJavaScript SPA

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

エリック・エヴァンスのドメイン駆動設計

来年もよろしくお願いします。

安全なWebアプリケーションの作り方1

読書会でのメモ

HTTPとセッション, 同一生成元ポリシー

HTTP

• クライアントからサーバへのリクエスト、サーバからクライアントへのレスポンスで構成されるプロトコル
• リクエストラインの構成は以下
• メソッド
• リクエストURL
• プロトコルバージョン
• 実際にはGET /hoge.php HTTP/1.1といった形式となる
• リクエストヘッダにはRefererなどがつく
• Refererはアプリケーションが意図した遷移を経ているかをサーバ側で検証する場合などに用いられるが、改変が容易
• URLにセッションIDなど機密情報が含まれる場合にはセキュリティリスクとなる
• レスポンスメッセージの構成は以下
• ステータスライン HTTP/1.1 200 OK
• ヘッダ Date: foo Server: Apache/2.2.14...
• 空行
• 本体 <body>...
• レスポンスヘッダはContent-lengthやContent-Typeなどが代表的
• Content-TypeはMIMEタイプというリソースの種類を指定するhtmlであればtext/html, jpg画像であればimage/jpg, pdf文書であればapplication/pdf
• 特殊記号や日本語などのマルチバイト文字列をURL上に記述する場合はパーセントエンコーディングを行う必要がある
• GET/POSTについて
• GETメソッドを用いる場合は、「リソースに対して副作用を起こさない・機密情報を送信しない・送信するデータ量が少ない」場合に用いるのが望ましい
• Referer経由で情報が漏洩する・アクセスログに記録されるため
• hiddenパラメータは書き換え可能
• HTTPには認識機構が用意されている
• Basic認証
• Digest認証

$user = $_SERVER['PHP_AUTH_USER'];
$pass = $_SERVER['PHP_AUTH_PW'];
if (!$user || !$pass) {
  header('HTTP/1.1 401 Unauthorized');
  header('WWW-Authenticate: Basic realm="Basic Authentification Sample"');
  exit;
}

• Basic認証が設定されているサーバから401のレスポンスを受け取ると、ブラウザはBasic認証のidとpassを受け取るダイアログを表示する
• 認証に成功すると、ブラウザはリクエストヘッダにAuthentificationを付与して送信し、ページの閲覧が可能となる
• Cookieとセッション管理
• HTTPはステートレスなプロトコルであるが、クライアント・サーバ間でログイン状態やその他の情報を記憶しておきたい場面が存在する
• 認証状態の管理はセッション管理と呼ばれ、HTTPではブラウザのCookieを用いて実現される
• 有効期限の設定されていないCookieはSessionと呼ばれ、ブラウザが閉じられるまで有効となる
• Cookieは文字列長および利用者による変更が可能なため、Cookieにはセッションidのみ記録し、実際のセッション管理を行う値はサーバ側で保持することが多い
• セッションidに求められる要件は以下
• 第三者がセッションidを推測できない
• 第三者からセッションidを強制されない
• 第三者にセッションidが漏洩しない
• 上記を満たすため、セッションには以下のようなことを考慮する必要がある
• 乱数の質
• ネットワーク的な盗聴の危険性
• XSSからの漏洩
• CookieのDomain属性/Secure属性/HttpOnly属性
• Referer

Socket.IO 1.0の解説記事を書いた

英語難しい https://medium.com/@sisidovski/wrote-an-article-about-socket-io-1-0-cf63d5fc9ae4

TemplateMethodパターンの雑感

メモ

• ロジックの手順を定義し、個々のロジックの実装はサブクラスに先送りするパターン
• コード再利用のための基本的な話
• 抽象クラスが定義するのは以下
  • 具象メソッド（テンプレートメソッド）
  • 抽象メソッド
  • フック
• フックはクラス内で何もしないか、またはデフォルトの振る舞いを実行する
  • サブクラスで適宜オーバーライドもできる
• サブクラスがテンプレートメソッドを変更しないようにfinal修飾子を宣言しておく必要がある
• 「こちらを呼び出さないでください。こちらから呼び出します。」
  • スーパークラスが主導権を持ち、必要に応じてサブクラスを呼び出す（実処理を実行する）ように設計するべき
• Storategyパターンと混同しがちだが、Storategyパターンはコンポジションを用いてロジックをカプセル化するのに対して、TemplateMethodパターンは継承を用いてロジックをカプセル化する
• FactoryMethodはTemplateMethodの特化型と言えるかもしれない
• サブクラスがスーパークラスを呼び出すことは許されないのか？
  • 原則はNoだが、実際はスーパークラスのメソッドを呼び出したい場面がある。循環する明示的な依存はできれば避けたい
• スーパークラスが定義する抽象メソッドの数が多すぎると実装が超めんどくさいと思うのだが
  • ロジックの粒度を意識するのが大事。細かくし過ぎると実装は大変になる
  • とはいえ、これは設計の柔軟性とトレードオフな気がする
  • オプションとしてフックが利用できるから、全てを抽象メソッドとせずにオプショナルなロジックはフックにするとよい

実例

• JavaのArray.sort()など
  • 教科書通りには設計されていないが、「実装をサブクラスに先送りする」という思想が存在する

実装

• 時間がない

Adapterパターンの雑感

メモ

• 既存のクラスがあり、そのインターフェースが使いにくい、求めているインターフェースと異なる場合に適用するとよい
  • Adapterパターンによってクライアントが期待するインターフェースに変換することができる
• アダプタの実装は、ターゲットインターフェースの大きさや煩雑さにより必要な作業量が変わる
• コンポジションを使うオブジェクトアダプタと多重継承が前提のクラスアダプタが存在する
• なぜオブジェクトをラップするか
  • アダプタは「オブジェクトのインターフェースを変換するために」オブジェクトをラップする
  • デコレータは「新しい振る舞いや責任を追加するために」オブジェクトをラップする
  • ファサードは「インターフェースの簡素化のために」オブジェクトをラップする
• 複数のインターフェースをラップするのか
  • Facadeパターンを使おう。Adapterパターンの目的はインターフェースを「変換」するためである
• システムに古いインターフェースを期待する部分と新しいインターフェースを期待する部分がある
  • 双方向アダプタを用いる。アダプタは関連する複数のインターフェースを実装する

実例

• Javaの古いインターフェースであるEnumerationインターフェースを使っているが、新しいインターフェースであるIteratorを使いたい。こういう場合にAdapterクラスを作成しIteratorインターフェースを実装する
  • クライアントはIterator型のオブジェクトとしてEnumerationを透過的に呼び出すことができる

実装

• 時間がない