引越し

台東区に引越した。 江東区の端から直線距離で8kmしか動いていないけど、それだけで周辺環境がかなり便利になった。 学生時代に住んでいたつくば市では10km移動しても草原しかなかったので、こういうところは都会感がある。

これで3回目の引越しだけど、物件探しから自分でやるのは初めてだった。 概ねうまく行ったけど、NTTに転居連絡をするのが遅かったせいで一週間くらい固定回線が使えなくなったのは失敗だった。 その間、auWiFiスポットを探す旅に出る羽目になった。

f:id:shkh:20171203194132p:plain

固定回線は転居に合わせてプランを変更したら恐ろしいほど速くなった。 夕方から深夜でも下り300Mbpsくらいは出ている。 上の画像は日曜の19:30に測ったもの。 ギガラインという上下最大1Gbpsのベストエフォートのプランで3500円/月くらいなので、期待をかなり上回った。

f:id:shkh:20171203191113j:plain

部屋の中は、引越し業者に粗大ごみの搬出をしてもらえると聞いてソファやテーブルなどを捨てた結果、生活感が消えた。 あとは、この後ろにベッドがあるだけ。 ただ、どうしてもこのままではゲームがしづらいので、やはりソファはいずれ買い直すと思う。

住み始めて一週間しか経っていないけど、日比谷線の通勤ラッシュはマジ卍。


引越しダイジェスト

  • 物件探し
    • 最寄り駅を選ぶのにhome'sの快適通勤検索が便利 -> https://www.homes.co.jp/chintai/comfort-commute/
      • 家賃相場が低くて快適な穴場が意外と見つかる
    • suumoで探せば十分
      • 特殊な条件でも無ければ不動産屋に対面で探してもらうのはコミュニケーションの時間が無駄だった
      • 気になる物件をリストアップして取扱不動産の中からそのリストの物件を多く扱うところで一気に内見だけさせてもらう
    • 即入居可 ≒ 即入居必須
      • 何件か確認したけど即入居可の場合は申し込みから二週間程度での入居を求められた
    • コンセントの数と位置は重要
      • 光コンセントとテレビコンセントは大抵隣り合わせで場合によってはそれらの位置で家具のレイアウトが決まってしまう
      • コンセントの数も重要で1Kで3箇所は欲しい
    • 費用交渉はルーチンっぽい
      • 他の物件と比較していると電話で不動産屋に言っただけで「費用交渉します!」と言われて数分で貸主の手数料が消えた
        • 機械的に処理されている速度だった
  • 引越し業者選び
    • 見積もり時に色々お願いする
      • 大手だからなのか粗大ごみの搬出や家電リサイクル法対象製品の回収も対応してもらえた
  • 手続き
    • 電気・ガス・水道は一週間前の連絡で間に合う
      • 各社のサイトに目安時期が載っていて単純な転居だと一週間前後だった
        • 電気・ガスは自由化で他社に乗り換えるならもっと掛かるのかも
      • ガスだけ停止・開始ともに立ち会いが必要だった
    • インターネット回線は余裕を持って予約が必要
      • 比較的空いていそうな11月でも二週間前にNTTに連絡したのでは遅かった
      • 休日だと3000円くらい工事費が高くなる
      • プラン変更するなら別でやると工事費が別途掛かるので転居のタイミングで申し込む
    • 役所関連は「転出 -> 引越し -> 転入 -> 免許」の順
      • 転出は引越し前にやっておくと良い
        • あとから旧住所の役所に戻るのは面倒だった
        • 郵送でもできるけど時間が掛かって後続の手続きがスタックしそうだった
      • 免許の住所変更は新住所の証明が必要なので転入時に住民票をもらっておく

「プロダクションレディマイクロサービス」を読んだ

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

最近、分散トレーシングの導入を目論んでUberのJaegerを触っていて、分散トレーシングはマイクロサービスの文脈で語られることも多いので無関係ではないということで読んだ。著者がUberのSREということもある。この本はマイクロサービスアーキテクチャを採用する際 / した後に、それを「プロダクションレディ = 本番対応」なサービス水準に押し上げて維持していくためのエッセンス集のようなもの。マイクロサービス自体の解説は殆ど無いので、Sam Newmanの「マイクロサービスアーキテクチャ」とかMartin Fowlerのブログを読んでおいた方が良い。

マイクロサービスアーキテクチャの適否については散々語り尽くされてきて通念化してるものがあって、プロダクトのライフサイクルとか組織が受ける制約とか種々の要因で適するものは限られるけど、この本に書かれている殆どのことはアーキテクチャに依らず有益だと思う。マイクロサービスアーキテクチャを採るとより一層必要性が高まるというだけ。 ろくに考えずに部分的に取り入れると崩壊しそうなものもあるので注意が必要だけど、可能な限り実践していきたい。

達成度を測定するチェックリストが各章末に付いていて、それが良く纏まっているので使えそう。


メモ

  • 1章 マイクロサービス
    • 4層モデル
      • マイクロサービス, アプリケーションプラットフォーム, 通信, ハードウェア
      • 下位3層インフラストラクチャレイヤの抽象化
    • エコシステム
      • 複数のマイクロサービスと抽象化されたインフラストラクチャレイヤ
  • 2章 本番対応
    • エコシステム全体で高い品質を維持
      • 可用性確保 / 高いSLAの実現
      • エコシステム全体の標準化
        • 共通的に現実に適用でき測定可能な標準と要件
        • 8つの原則
          • 安定性, 信頼性, スケーラビリティ, 耐障害性, 大惨事対応, パフォーマンス, 監視, ドキュメント
  • 3章 安定性と信頼性
    • カナリア
    • 依存関係の障害に対する防御策
      • バックアップ / 代替サービス / フォールバック / キャッシュ
  • 4章 スケーラビリティとパフォーマンス
    • 並行性とパーティション分割
    • 成長の判断基準
      • ビジネスメトリックに基づく質的基準
      • 質的基準を定量化した量的基準
  • 5章 耐障害性と大惨事対応
    • 障害シナリオ
      • 内部障害 (マイクロサービス自身) と外部障害 (依存関係, 下位レイヤ)
    • 回復性テスト
      • コードテスト (lint, UT, IT, E2E) , ロードテスト, カオステスト
    • インシデント対応の5ステップ
      • 評価, 調整, 緩和, 解決, フォローアップ
  • 6章 監視
    • 主要メトリック
      • マイクロサービスメトリックとインフラストラクチャメトリックへの分類
  • 7章 ドキュメントと組織的な理解

「Real World HTTP」を読んだ

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

良著だった。 ここ一ヶ月くらいがっつり手を動かす時間が取れなかったので、隙間時間で読める本として選んで通勤時間とか使って読んだ。

この本はプロトコルの解説書ではないし、ITエンジニア向けのHowTo本でもなく、HTTPの変遷を軸とする歴史書、というのがしっくりくる。 HTTP/0.9からHTTP/2.0に至るまでを、クライアントの多様化やアプリケーションのリッチ化といった環境変化に対して、障壁を乗り越えながらそれを実現してきたWeb技術、そしてそれを支えるように進化してきたHTTPという形で構成されている。 そして、それぞれのトピックが著者の実地での知見で肉付けされていて、"Real World"感がある。

個々の技術については、その詳細は他に譲っていて、Webの発展の過程を伝えるのに必要十分な解説がなされていると思う。 それによって、自分の中の知識を体系立てて整理できる。 こういう位置付けの書籍は他にないか、アップデートされていないので、今後も加筆を続けてほしい。

「HTTPはインフラ」という表現が途中で何度か出てきて、最初は腑に落ちないが読み終えると意図することが伝わってくる。 おすすめ。