そこに仁義はあるのか(仮)

略してそこ仁!

認知バイアスを知って考えのズレを意識する

認知バイアスとは、人間が何かを考えたり記憶したりする際に持ってしまう先入観のことです。良く聞く「希望的観測」や「生存バイアス」もこの認知バイアスの中の一つです。
本来は論理的かつ合理的な決定をしなければならないときに、認知バイアスの影響をうけてしまうと結論がズラされてしまう可能性があります。認知バイアスを理解し、意識することで、思考が逸れてしまうことを防ぐようにしなければいけません。
もしくは、逆に認知バイアスがかかることを逆手に取れば、物事を円滑に進められるかも。
Wikipediaを見ると、数多くの認知バイアスが掲載されています。一つ一つを見ると、「確かにやってしまいがちかも。」と思うような認知バイアスが数多く紹介されていました。

f:id:syobochim:20200418173624p:plain
Category:認知バイアス - Wikipedia

以下は、Wikipediaと書籍『リファクタリング・ウェットウェア』を参考に、いくつかの認知バイアスを短くまとめてみました。
発生していそうな状況も書いてみたので、「もっとこういう例の方が良いよ!」などアドバイスあればコメントいただけると嬉しいです。

  • 後知恵バイアス
  • アンカリング
  • 確証バイアス
  • 偽の合意効果
  • 希望的観測
  • コンコルド効果
  • 根本的な帰属の誤り
  • 自己奉仕バイアス
  • 心理的財布
  • 正常性バイアス
  • 生存バイアス
  • ゼロサム思考
  • ダニング=クルーガー効果
  • 単純接触効果
  • ツァイガルニク効果
  • ホーソン効果
  • レイク・ウォビゴン効果
  • 🤔 認知バイアスとどう向き合うのか
  • 最後に
続きを読む

【翻訳記事】デプロイ戦略の定義

この記事は2017/11の以下のブログ記事の翻訳です。
blog.itaysk.com

まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。

3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。
初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。
何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。



デプロイの話をしましょう。このトピックは、以前は面白くない細かい実装だと考えられていましたが、現在はモダンなシステムの基本要素になりつつあります。全ての人がデプロイの重要性を理解して、それを中心にソリューションを構築しようとしているように感じますが、私たちはデプロイ戦略の構造と定義をしていません。人々は同じ意味なのに違う言葉を使ったり、違う意味なのに同じ言葉を使ったりしています。これは、人々が問題を解決しようとして車輪の再発明をすることにつながります。私たちはより良いツールを構築し、より良い決定を下し、お互いのコミュニケーションをシンプルにするために、このトピックについての共通の理解が必要です。
この記事は、私が以下のように呼んでいる一般的なデプロイメント戦略について一覧化し、定義しています。

  • 無謀なデプロイ (Reckless Deployment)
  • ローリングアップグレード (Rolling Upgrade)
  • ブルーグリーンデプロイ (Blue/Green Deployment)
  • カナリアデプロイ (Canary Deployment)
  • バージョンデプロイ (Versioned Deployment)

これらのリストにはおそらく他の名前や用語があるかもしれません。ここに無い用語は、これらの主要なデプロイ戦略の変形とみなせると主張します。

記事を読む前の注意点:この記事は定義・方法論・アプローチについて書かれたものであり、どのような技術スタックで実装するかについては書かれていません。技術的なチュートリアルについては別のポストで書く予定です。お楽しみに!

無謀なデプロイ (Reckless Deployment)

別名:Highlander*1 , Simple

要約: 古いものを壊して、新しいものを構築する。結果は気にしない。

これは最も簡単な戦略です。全てを破棄し、新しいバージョンを再構築します。通常は、開発/テストのシナリオか影響度がとても小さいアプリケーションに適しています。これ以上の説明はありません…

f:id:syobochim:20200317190111p:plain

ローリングアップグレード (Rolling Upgrade)

別名: Gradual Deployment

要約:既存の環境に新しいバージョンのコードを導入し、古いコードを廃止しながら徐々に新しい環境を増やしていきます。

これは新しいコードを既存の環境に追加していく際の基本の戦略です。既存の環境は古いバージョンと新しいバージョンの混在プールになり、最終的にはゆっくりと古いインスタンスが新しいインスタンスに置き換わります。「インスタンス」と「プール」という用語は採用技術(VM、コンテナ、プロセスなど)によって違う意味になります。

f:id:syobochim:20200317190831p:plain

ヘルスチェックと監視

この戦略の重要な側面は、ヘルスチェックと監視です。新しいコードを徐々に導入していくことへの重要なポイントは、新しいコードで予期しない問題が発生した場合に、障害を制御できることです。そのためには、新しいバージョンがどう動作しているかを知らなければなりません。そのため、ヘルスチェックと監視が不可欠です。

ロールバック

デプロイがうまくいっていないと判断したら、リリースを止めてデプロイをキャンセルし、元に戻すこともできます。(別名:ロールバック)

後方互換性

新しいコードと古いコードが共存しているので、ユーザーはどちらのバージョンにもルーティングされる可能性があり、この戦略を使っている場合は後方互換性が主な懸念点になります。

ちなみに

あなたは、一部のユーザーが一貫して特定のバージョンを取得する、または、一部のユーザーのみに新しいバージョンを公開するために、ユーザーをスマートにルーティングすることを検討しているかもしれません。それは正しいですが、私はそれをローリングアップグレードとは呼びません。私が何を言おうとしてるのかはこのまま読み続ければわかります。

ブルーグリーンデプロイ (Blue/Green Deployment)

別名:Red/Black, Staged deployment, Swapping Slots

要約:現在の環境に影響を与えず、分割された新しい環境に新しいバージョンをデプロイします。

これは最も安全な戦略で、多くの本番環境で利用されています。安全性を確保するために、現在実行中の環境には一切手を加えず、アプリケーション全体のコピーやアップグレードするモジュールを別の環境に用意します。デプロイの範囲を決める(または分離の範囲)を決めるのはあなた次第です。
例えば
・システム全体を再構築するのか、更新があるモジュールだけをアップデートするのか。
・新しいバージョン用にロードバランサーを新規構築するのか、既存のロードバランサーに新しいルールを追加するのか。
・バージョン間で設定値を共有するのか。
これらは考えられる質問の一部に過ぎず、どう決めるかはあなたかあなたのツール次第です。
1つ確かなことは、新しいバージョンは現在のバージョンのデプロイから完全に分離されるべきということです。これは、アップグレードの間に新旧のコードが環境に混在するローリングアップグレードとは対照的です。その結果、後方互換性は必須ではありません。
新しいバージョンが公開されたら、それをテストすべきです。現行のバージョンはまだ稼働中なので、デプロイ完了を急ぐ必要はありません。この時点では、ユーザーはまだアップデートに気づいていません。
バージョンの品質に十分自身が持てたら、ユーザーを古いバージョンではなく新しいバージョンに切り替え始めます。一度に全てのユーザーを切り替える(別名:カットオフまたはカットオーバー)ことも、新しいバージョンに徐々にユーザーを追加することもできます。

f:id:syobochim:20200317212121p:plain

ドレイン

一般的な方法は移行前に古いデプロイを「ドレイン」することです。「ドレイン」とは、現在のアクティブなセッションが自然に終了し、新しいバージョンのみを使用して新しいセッションを開始することを意味しています。

スイッチバック

通常は、完全に移行した後も古いバージョンを保持しておき、簡単に元に戻してスイッチバックできるようにします。

ステージ

この戦略の一般的なバリエーションには、段階的なデプロイとスロット交換があります。デプロイのスコープ(または分離の範囲)はアプリケーション全体です。(つまり、システム全体のコピーがスタンバイ状態になっています。)この方法では、アップグレードが実行中でなくても、私たちは常にアプリケーションとインフラのコピーを2つ持つことになります。一つの環境は本番環境で、もう一つの環境は「ステージ」と呼ばれる本番前の環境です。私たちはQA / UAT / Repros(再現) / CIなどのために、定期的にステージを利用できます。私たちは常に本番環境ではなくステージにデプロイします。よって、ステージは常に本番環境の前にあり、最新の本番環境候補になります。通常のブルーグリーンデプロイのように、本番環境に影響を与えずにステージのテストと検証をすべきです。デプロイに成功したら、2つの環境間でルーティングを切り替えるだけで、ステージが本番環境になり、本番環境がステージになります。これは通常、DNSレコードの更新を利用します。(必ずしもそうではありませんが。)ここでも、何か問題が発生したら、簡単に元に戻せます。

ちなみに

あなたは、ステージ環境(または新しい「グリーン」なデプロイ)を公開して、実際のユーザーが環境を試すことを検討しているかもしれません。それは良いアイデアです。私はそれをカナリアデプロイと読んでいます。次の章で説明します。

カナリアデプロイ (Canary Deployment)

別名: Ringed Deployment, Feature toggling, Dark features, Silent launch, A/B testing, Testing in production.

要約:新しいバージョンを古いバージョンと一緒にデプロイして、新しいバージョンを使用するユーザーを慎重に制御します。検証を監視し、調整しつつ、徐々に人口を増やしていきます。

これはデプロイ方法の聖杯です。また、達成が最も困難です。
これは、前述の戦略を高度に使用したものと考えることができます。システムに新しいコードを導入する場合は、実際のユーザーが新しいバージョンを本番環境で使えるという重要な違いがあり、どの戦略でも使用できます。当然、全てのユーザーが全ての新機能を使える必要はないので、どのユーザーが新バージョンのどの部分を使うかコントロールする必要があります。これは、ロードバランサやプロキシレイヤーで実装することも、アプリケーションの設定を使うことも、ランタイムを使うことも、その他の方法で実装することもできます。カナリアの基本的で一般的な実装では、ブルーグリーンデプロイを利用し、一部のユーザーを新しい「グリーン」バージョンにスマートルーティングします。

f:id:syobochim:20200317221056p:plain

より高度な実装では、拡張されたブルーグリーンデプロイのテクニックを超えて、より詳細なレベルでデプロイします。カナリアはコントロールと監視が全てであり、コンポーネントをより細かくコントロールできるほど、カナリアデプロイはより高度になります。

さらなる監視

前述しましたが、今回はさらに重要な意味を持ってもう一度説明します。これらの高度なパターンは、いずれも適切な監視なしでは機能しません。カナリアでは、基本的な死活監視だけでなく、パフォーマンスやユーザーエクスペリエンスの指標の監視を検討してください。良い可観察性のカナリアによって、動作するバージョンをデプロイすることから、最適なバージョンをデプロイすることへと考えを移行できます。

A/Bテスト

高度な違いは、複数の異なるバージョンを本番環境へデプロイし、各バージョンでの実際のユーザーと彼らのリアクションの実験をしていることです。ここではデプロイメント戦略から成熟した製品計画アプローチに話題が移りますが、デプロイ戦略はこれらの高度なビジネス関連の戦略の重要な基盤であり、2つが密接に関連していることが多いので、ここで言及しています。

ダークフィーチャー

本番環境のカナリアデプロイ / テストの極端なバージョンでは、機能をオフにして本番環境にデプロイし、一部のユーザー(ベータ版やプレビュー版のテスター)に対して選択的に機能をオンにします。このように動作させるには、システムをモジュール化してデザインする必要があります。つまり、デプロイの単位が機能毎になっており、アプリケーションは個別に切り替え可能な機能で動的に構成されます。この場合、どの機能がどのユーザーに対して有効になっているかを管理するための専用リリース管理システムがあることは、悪いアイデアではありません。

バージョンデプロイ (Versioned Deployment)

要約:ユーザーが使用するバージョンを選択できるようにしながら、全てのバージョンを維持します。

これは厳密なデプロイ方法ではなく、アーキテクチャパターンまたはAPIデザインパターンの境界線なので、ここに属しているかはわかりませんでした。それでもデプロイ戦略に影響を与えるかもしれないので、ここでデプロイ戦略として挙げています。
各バージョンを選択する必要がなく、常に全てのバージョンを本番環境で稼働させたらどうでしょう?この魅力的な戦略は、API開発者の間で特に人気があります。この例では、全てのAPIバージョンが常に使用可能(作業バージョンを削除しない)で、ユーザーは使いたいバージョンを選んで使えます。これは、私たち(ユーザーではない)がユーザーが使うバージョンを決める他の戦略とは対照的です。
明らかな問題はレガシーバージョンをホストするための追加の容量と、バージョン間でデータソースを共有することです。しかし、もし後方互換性に十分に注意し、予備の追加容量を確保できるのであれば、こうした問題よりも利点の方が大きくなります。
このデプロイ戦略はとても単純で、新しいバージョンをデプロイするだけです。全てが常に明示的にバージョン管理されているので、新しいバージョンのデプロイを簡単に捨てても影響がありません。優れているところは、新しいバージョン(または任意のバージョン)の使用を明示的に要求する必要があるところです。そのため、デプロイ環境ではバージョン間のユーザーの移行を気にする必要がありません。

f:id:syobochim:20200317224903p:plain

APIデザイン

この記事はAPIの設計に関するものではないので、ここでは具体的な例を取り上げません。しかし、この戦略に興味がある場合は、MicrosoftがAzure Resource Manager(ARM) APIをどのように設計したかを見てみてください。これは、このパターンの素晴らしい例であり、一般的なREST APIの設計にも適しています。

まとめ

以上です!これらは私が不可欠だと考えているデプロイ戦略であり、それらがどう定義され、どう違うと私が考えているかを説明しました。
以下の戦略についてカバーしました。

  • 無謀なデプロイ (Reckless Deployment) - 何も気にしない時
  • ローリングアップグレード (Rolling Upgrade) - ロールバックする時間を確保するために、徐々にデプロイする
  • ブルーグリーンデプロイ (Blue/Green Deployment) - 変更の操作から本番サービスを守り、横の環境で変更を操作することで、安全性を高める
  • カナリアデプロイ (Canary Deployment) - 実際のユーザーに新しいバージョンを公開する
  • バージョンデプロイ (Versioned Deployment) - 複数のバージョンを永久に共存させる特別な目的の設計

*1:翻訳者コメント:Wikipediaを見ると、「外界と隔離にまでは行かないにしても交流が困難で、文明の浸透が遅く、生活環境が快適とは言いがたいハイランド」に住む人とあるので、時代遅れという意図のようです。

「DevRel/Online #1 〜初のオンライン開催〜」に参加してオンライン勉強会のノウハウを得ました! #devreljp #devrel

DevRel Meetup in Tokyo主催の勉強会がオンラインで開催されたので参加しました!
コロナの影響で初のオンライン開催になったそうですが、家でご飯の準備をしながら見られるので気軽に参加できて嬉しい。
そしてtwitterを見ていると東京以外にお住まいの方も参加されていたようで、「DevRel Meetup in Tokyo」の幅が広がったのを目の当たりにした感じで、すごくよかったです!
ただ、今回はWebEXを利用した勉強会でしたが、ネットワークや音声、画面共有でのトラブルが多く、時間がかなり伸びていました。オンライン勉強会の課題ですね…。
イベントのメインテーマはイベントページでは定義されていないようですが、アジェンダ的には「オンライン勉強会のノウハウ」に関するセッションばかりでした。

イベントページはこちら
devrel.connpass.com

  • 💬 DevRelの基本とオンラインミートアップの作り方 by アツシさん
    • イベントの基本的な作り方
      • 2. イベントを企画する
      • 4. イベントを実施する
      • 5. 参加者を保持する
  • 💬 オンラインイベントを実施する上で私は何を考えどう行動したか by 鈴木さん
  • 💬 Online Demoを通じてスピーカーの注意点をまとめてみる(´Д` )テスト by おだしょーさん
  • 🤔 セッション中のDEMOについて
  • 🙌 おまけ
  • 最後に
続きを読む

SSL/TLSを実際に設定しつつ学べる「SSLをはじめよう!」を読んだ

@mochikoAsTechさんに「SSLをはじめよう!」という同人誌をいただきました!元々「SSLは完全マスターすらできてない」という状態で、この本が発売されたら購入しようと思っていたのですごく嬉しい!技術書典8で発売される予定だったのですが、コロナの影響で技術書典自体がなくなってしまいました…。残念…。ただ、オンラインでの購入が可能です!

「はじめに」にも書いてありますが、この書籍はSSLに対して『関わる機会が多い割に「ちゃんとわかっているか」と言われるとちょっと自信がない』と言う人に向けられた書籍です。私じゃん。
全部で100ページ強で操作画面のキャプチャも多く、私はサクサクと2日で読めてしまいました。しかし、その中に、

  • SSL/TLSとは何か
  • どういうメリットが得られるのか
  • HTTPSはどういう流れで処理が行われるのか
  • 実際にHTTPS化をやってみる
    • クラウド環境の準備(Oracle Cloud)
    • Webサーバーの構築
    • SSL証明書の取得
    • SSL証明書の設定

と、内容の密度が高く、SSL/TLSに対する理解をしっかり深められました。
特に私が気に入ったのは、実際にHTTPS化をしていく箇所です。ハンズオンのようにキャプチャが貼られているので迷わずに操作ができるし、手順に「自分が今なんのために何をやっているのか」が丁寧に解説されているので、操作の目的を意識しつつ進んでいけました。
正直、これで1000円はお買い得だと思う…!

📖 目次

  1. SSL/TLSとは?
  2. Oracle Cloudのアカウントを作ろう
  3. サーバを立ててHTTPでサイトを見てみよう
  4. SSL証明書を取ってHTTPSでサイトを見よう
  5. SSL/TLSの仕組み

HTTPS化すると得られるメリット

HTTPのままだと起こるデメリットとHTTPSにすることのメリットが紹介されています。
その中で特に面白いと思ったのは、HTTP/2による速度向上に関する記載でした。

HTTPS化すると、HTTP/2を利用できる*1ようになり、ページの作りによっては速度が向上するとのこと。

こちらはHTTPとHTTPSの速度比較ができるサイトです。
HTTP vs HTTPS — Test them both yourself
右上のタブでHTTPとHTTPSを切り替えられて、それぞれのプロトコルでのページロードの速度を実際に確認できます。
やってみると、かなりHTTPSの表示が早いのですが、このサイトのように「小さな画像を大量に表示するサイト」はHTTP/2のメリットを受けやすいそうです。

SSL証明書の秘密鍵にパスフレーズは設定すべき?

opensslコマンドで秘密鍵を作成する時に、パスフレーズを設定するべきかどうかのコラムがありました。秘密鍵にパスワードをつけることでどんなメリットとどんなデメリット(運用の手間)があるかという内容を紹介した上で、以下のように記載があります。

利便性を保ちつつ安全性も向上させたければ、本番のウェブサーバで使う秘密鍵はパスフレーズなし、バックアップとして他のサーバで保管しておく秘密鍵はパスフレーズありにしておく、という方法がいいでしょう。

こういう、実際に運用する時はどういう風に判断すれば良いのか、という指標が載っているのも読んでいて楽しかったです。
他にも「ロードバランサーでSSLターミネーションするメリット」が書かれたコラムもあり、そちらも面白く読めました。

Chapter3〜Chapger4 実際にHTTPS化をする

Chapter3〜Chapter4で実際にクラウド環境の構築からHTTPS化までの流れを進めていきます。
100ページの中でSSL/TLSについて学べる上に、クラウドのアカウント登録・Webサーバの構築・HTTPS化という幅広い範囲がカバーされており、とても内容密度が高いです。
クラウドを利用することで環境構築も簡単+素早くできて、実際に手を動かしながらサクサクと試しつつ理解を深めることができました。
実行するコマンドについても意味が説明されていて、「こういう意図のコマンドを実行しているんだ」と理解しつつ進めていきました。

これらのチャプターは自分のドメインを持っていることが前提になるので、「お名前.com」でドメインを取得しました。「.work」のドメインであれば1円で取得できますし、ドメイン取得までの手順も全然難しくないです。ただ、もしドメイン取得の手順に不安がある方は、同じく@mochikoAsTechさんが書かれている「DNSをはじめよう!」を書籍でご案内されていました。

追加で調べたこと

書籍には載っていませんでしたが、追加で調べたことを書きます。

Qualys SSL Server Test

Qualys SSL Server TestはSSLの設定を無料でチェックできるサイトです。URLを入れるだけでサイトのSSL設定のセキュリティ強度を表示します。
https://www.ssllabs.com/ssltest/analyze.html

f:id:syobochim:20200302214803p:plain:w400
NginxのHTTPSの設定に

ssl_protocols TLSv1.2;

を入れるか入れないかで、Protocol Supportの点数が変わったりして面白いです。

HSTS(Hypertext Strict Transport Security)

HTTPSでアクセスしたいサイトにHTTPでアクセスした時、Nginxのconfigにリダイレクトの設定を入れているのに初回のみリダイレクトされませんでした。
これはHSTSの設定ができていないことが原因でした。
HSTSは、WebブラウザにTLSの使用を強制するポリシーメカニズムとのこと。
Strict-Transport-Securityヘッダーに「max-age」「includeSubDomains」「preload」を設定すれば強制的にHTTPSへアクセスさせることができました。

nginxの設定 (HTTPの設定のみ抜粋したdiff)
server {
    listen       80;
    server_name  localhost;
    return 301 https://$host$request_uri;
+     add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

📖 まとめ

本を読む前は「SSLは難しそうで少し怖い」という状態でしたが、概念を理解しつつ実際に手を動かしてHTTPS化の設定をしてみたことで、SSLが怖くなくなりました!
SSLの概念の説明だけでなく、クラウド環境の登録・Webサーバの構築・サイトのHTTPS化という幅広い操作手順も説明されている、密度が高い一冊です。
操作する画面のキャプチャが貼られているのでひとりでも迷わずに進められますし、手順には「どんな目的のためにこの操作をしているのか」が丁寧に解説されており、操作しつつしっかりと理解を深められました。
SSLに対して苦手意識のある方にオススメです!




*1:HTTP/2は、仕様上はHTTPにも対応しているけれど、ブラウザ側がHTTPSでしかHTTP/2を利用できないようになっている。

「Web開発者のための大規模サービス技術入門」は実践的な技術を学べる一冊でした

「株式会社はてな」さんのインターンシップでの講義内容をまとめた本とのことで、大規模サービスを構築・運用するということに特化した実践的な内容が多い、とても良い本でした。概念的な話だけではなく、実際にシステムを運用した経験からくる、「仮想化によってどれくらいのボトルネックが発生するか」「キャッシュサーバーに最適な要領はどれくらいか」というような話も多い本でした。人に勧めたくなる一冊。
インターン生にむけた講義内容を収録した講義ベースの本ということで、解説も丁寧でわかりやすかったです。
ただ、おそらくインターン生のレベルが高く*1、先日「インフラエンジニアの教科書2」を読んでおいてちょうど良いレベルの難易度でした。小規模のWebサービスを構築する際の基礎知識はある程度わかっているとサクサクと内容が入ってくると思います。
この本の初版は2010年8月とのことで、「当時とは採用している技術も違うんだろうな〜」と思いながらも大規模サービスを運用する上で基本となる考え方はしっかりと学べました
個人的には口語で書かれている箇所が多く、文語の方が読む負荷は少なかったな〜、と感じました。

📖 目次

  • 第1回 大規模Webサービスの開発オリエンテーション―全体像を把握する
  • 第2回 大規模データ処理入門 ―メモリとディスク,Webアプリケーションと負荷
  • 第3回 OSのキャッシュと分散 ―大きなデータを効率良く扱うしくみ
  • 第4回 DBのスケールアウト戦略 ―分散を考慮したMySQLの運用
  • 第5回 大規模データ処理[実践]入門 ―アプリケーション開発の勘所
  • 第6回 [課題]圧縮プログラミング ―データサイズ,I/O高速化との関係を意識する
  • 第7回 アルゴリズムの実用化 ―身近な例で見る理論・研究の実践投入
  • 第8回 [課題]はてなキーワードリンクの実装 ―応用への道筋を知る
  • 第9回 全文検索技術に挑戦 ―大規模データ処理のノウハウ満載
  • 第10回 [課題]全文検索エンジンの作成 ―基本部分,作り込み,速度と精度の追求
  • 第11回 大規模データ処理を支えるサーバ/インフラ入門 ―Webサービスのバックエンド
  • 第12回 スケーラビリティの確保に必要な考え方 ―規模の増大とシステムの拡張
  • 第13回 冗長性の確保,システムの安定化 ―ほぼ100%の稼動率を実現するしくみ
  • 第14回 効率向上作戦 ―ハードウェアのリソースの使用率を上げる
  • 第15回 Webサービスとネットワーク ―ネットワークで見えてくるサービスの成長
  • 特別編 いまどきのWebサービス構築に求められる実践技術 ―大規模サービスに対応するために

「大規模サービス」はどれくらいの規模?

書籍の中では、インターン実施時と書籍執筆時の2回、はてなさんのサービス規模について記載されています。
ご参考までに載せておくので目安として考えてください。1年足らずでもユーザー数、ハードウェア数がすごく増えています。

2009/8時点

  • 登録ユーザは100万人以上、 1,500万UU(ユニークユーザー)/月
  • 数十億アクセス/月 (画像などへのアクセスを除く)
  • ピーク時の回線トラフィック量は430Mbps
  • ハードウェア(サーバ)は500台以上

2010/4時点

  • 登録ユーザ数は150万人、1,900万UU/月
  • 数十億アクセス/月 (画像などへのアクセスを除く)
  • ピーク時の回線トラフィック量は850Mbps
  • ハードウェアは600台以上(22 ラック)

本の内容と現在のはてなさんのインターン資料 / 研修資料

はてなさんはインターン資料も新入社員への研修資料も公開してくれています。こちらの内容と本の内容は、対応領域があまり被っていない感じなので、ベースとして求められるスキルセットが変わってきたのかもしれません。
講義パート - はてなサマーインターン2019 レポートサイト
GitHub - hatena/Hatena-Textbook: はてな研修用教科書

公開されている研修資料の中に「インフラ屋さん、今昔物語」というスライドがあり、その中には

  • 2007年〜2015年:クラウドシフト期
  • 2013年〜2017年:サーバレスアーキテクチャの幕開け

と記載されているので、2010年出版の書籍とは状況も違いますね。
Hatena-Textbook/slide.pdf at master · hatena/Hatena-Textbook · GitHub
書籍にはクラウドサービスに対して「アプリケ=ションやDBを本格的に置くというのはまだ時期尚早と考えています。」と記載があるのに対して、2019年インターン資料ではAWSのデプロイが講義内容に組み込まれているようでした。
採用技術が2020年にアップデートされた書籍も読んでみたい…!

実践的な内容が多く記載されている

利用ユーザーとトラフィックがとても多いWebサービスの負荷をどのように運用していくのかの実践的ノウハウがたくさん詰まっていました。
圧縮のアルゴリズムや全文検索の内容が組み込まれているのははてなさんのインターンらしいな、と思いつつも、大規模Webサービスになると確かに欠かせない技術だと思います。
また、メモリが安く購入できるという状況から、チューニングをやるのとメモリを増設するのでどちらを選択するか検討する、など、サービス運営する上で意識するポイントも書かれています。
インデックスをつける前後でどれくらいSQLの応答時間に差が出るか、など、大規模なデータを使った実行結果も載っています。

マスタ / スレーブの冗長構成はマスタ1台+スレーブ3台=4台必要

マスタ1台+スレーブ2台=3台の場合

スレーブの1台が故障したら、リカバリのために新しいサーバにデータをコピーする際にサービスが停止する。
スレーブへのデータコピーのために

  • スレーブを止めたら参照ができない
  • マスタを止めたら書き込みができない

→冗長構成は取れていない。

マスタ1台+スレーブ3台=4台の場合

スレーブ3台のうち、1台が故障した場合でも、スレーブの2台のうちの1台を止めて新しいサーバにデータをコピーすることで、無停止リカバリができる。(ただし、リカバリ時に稼働しているサーバの負荷は高くなる。)

MySQLのストレージエンジン MyISAMとInnoDB

MyISAMとInnoDBのそれぞれにどのような特徴があって、どういうケースでどちらを選択するのか。

アクセスパターン 適したストレージエンジン
追記しかない MyISAM
更新頻度が高い InnoDB
トランザクションが必要 InnoDB
SELECT CCOUNT(*)を使用 MyISAM

💬 まとめ

「Web開発者のための大規模サービス技術入門」は大規模サービスに特化したシステム構築・運用について学べる一冊でした。
インターン生にむけて、実際に知っておいて欲しい内容が盛り込まれているので、すごく実践的な内容です。
利用技術は2010年のものなので、現在とギャップはあると思いますが、概念や考え方などを学ぶ上ですごく役に立つので、人にお勧めしたくなる本でした。

*1:文中で「形態素解析のMeCabを半数以上の参加者が使ったことがある」などの記載がありました。

インフラエンジニアの必須知識を広く体系的に学べる「インフラエンジニアの教科書2」を読んだ

インフラの知識が割と必要な仕事だけど、「あれってなんだっけ?」と調べることが多く、「ちゃんと勉強しないとな〜」と思っていたときにお勧めいただいたのが「インフラエンジニアの教科書2」でした。(ちなみに「インフラエンジニアの教科書1」は読んでないのですが、全然問題なかったです。今後1の方も読んでみよう。)
プロトコルやOSから、セキュリティ攻撃、RFCの読み方など、本当に幅広い必須知識が紹介されています。(目次参照)
今まで曖昧に / 所々で理解していたことを体系的に学べました。また、いくつかのChapterでは、「インフラエンジニアは何を意識すべきか」という内容も盛り込まれていてすごく良かったです。
全体的に図解も多く、かなりサクサクと読めました。

インフラエンジニアの教科書2 スキルアップに効く技術と知識

インフラエンジニアの教科書2 スキルアップに効く技術と知識

  • 作者:佐野 裕
  • 出版社/メーカー: シーアンドアール研究所
  • 発売日: 2016/08/26
  • メディア: 単行本(ソフトカバー)

📖 目次

  • CHAPTER-01 プロトコル
  • CHAPTER-02 OS
  • CHAPTER-03 ネットワーク
  • CHAPTER-04 データベース
  • CHAPTER-05 WEBのサーバサイド開発言語
  • CHAPTER-06 共通鍵暗号方式と公開鍵暗号方式
  • CHAPTER-07 障害対策と障害対応
  • CHAPTER-08 よく知られたセキュリティ攻撃
  • CHAPTER-09 インターネットの運用と発展をつかさどる組織や団体
  • CHAPTER-10 RFCの読み方と作られ方
  • CHAPTER-11 世界規模のインターネットサービス運営
  • CHAPTER-12 インフラエンジニアとして目指す方向

「インフラエンジニアの〇〇」

Chapter2〜4の『インフラエンジニアの〇〇』では「Chapterのコンテンツに対してインフラエンジニアがどう関与するか」という内容が書かれており学びが多かったですし、本書籍の特徴的な部分だと感じました。

  • Chapter2-6 インフラエンジニアのプロセス管理
  • Chapter2-9 インプラエンジニアのメモリ管理
  • Chapter2-13 インフラエンジニアのファイル管理
  • Chapter3-16 インフラエンジニアのネットワーク管理
  • Chapter4-20 インフラエンジニアとデータベース

例えば、「Chapter3-16 インフラエンジニアのネットワーク管理」から抜粋すると、

「主に監視するのはdiscatd(packet loss)とunbind」

ネットワーク機器で監視できる項目は多々ありますが、[ 1 ] 特にdiscard値とunbindの発生は特に注視すべき監視項目です。
パケットロスなどにより発生するdiscard(packet loss)値は常に0であるべきですが、ちょっとしたdiscardはたまに発生します。discardが発生した場合、原因を徹底的に分析するのが好ましいです。discardが発生しうる要因として、[ 2 ]接続先機器側の問題、ケーブル不良、スイッチバッファが溢れたなどがあります。特に外部からのリクエストが多い環境においてはネットワーク機器のCPU使用率が高い場合やキャッシュを使い果たすほどの瞬間的に大量のパケットが流れ込んだ時にパケットロスが発生しやすくなります。このような場合は、[ 3 ]ネットワーク構成を変更してトラフィック流入を物理的に減らす方法や、より高性能のスイッチに買い替えるといった方法があります。

のように「[ 1 ]何に注意すべきか」「[ 2 ]どんな原因があるか」「[ 3 ]どういう対応をするか」という内容が盛り込まれています。
また、障害対応方法以外にも、設計時にどんなことを意識するかという内容も書かれています。

CHAPTER-07 障害対策と障害対応

「障害発生した時にスピード解決するために、サーバの状態を把握するための操作は自然に手が動くようにしておきましょう」という内容のChapterです。
すごく実用的で、障害発生時、各調査事項に対してどんなコマンドを実行するのかというのが載っています。
これさ〜〜〜、いっつもなんだったっけって調べるよね〜〜〜〜〜、助かる〜〜〜〜〜、覚えなきゃ〜〜〜〜〜〜〜。
インフラエンジニアの方が実際に利用している重要なコマンドを一括で覚えられるようにしてくれていてとても助かります。

コマンドメモ。見返す。
  1. メモリ搭載量と使用量は?
    • # free
  2. パーテーションごとのディスク使用量と空き容量は?
    • # df -h
  3. 使われているCPUは何で、コア数は全体でいくつか?
    • # cat /proc/cpuinfo | grep -e "model name" -e cores
  4. ディスクのRAID構成は?
    • # MegaCli -LDInfo -Lall -aall | grel RAID
    • # hpssacli ctrl all show config
  5. CPU使用率は高いか低いか?
    1. # w
    2. # top -d 1
  6. 現在のディスクアクセス率は高いか低いか?
    • # iostat 1
  7. 現在張られているTCPコネクションの数は?
    • # netstat -an | grep ESTABLISHED | wc -l
  8. 現在サーバにログインしているアカウントは何か?
    • # last | grep "still logged in"
  9. サーバが起動してからの経過時間は?
    • # uptime
  10. Webサーバの場合、ApacheやNginxなど、何のWebサーバソフトウェアが動いているか?
    1. # netstat -lnp | grep 80
    2. # ps -ef | grep [プロセス番号]
  11. DBと連携しているWebサーバの場合、何のDBサーバソフトウェアと接続しているか?
    • netstat -an | grep ESTABLISHED
    • ※ポート番号で判断する。
  12. メモリ / ハードディスク / 電源ユニットが故障していると仮定して、その証拠はどうやって調べるか?
    1. # dmesg
    2. # more /var/log/messages
  13. サーバにはUSBメモリが接続されているか否か?
    1. # dmesg
    2. # parted -l
    3. # lsusb
  14. ネットワーク機器とサーバのネットワークインターフェースは何Gbpsで接続されているか?
    • # ethtool eth0 | grep Speed

おまけ


💬 まとめ

「インフラエンジニアの教科書2」は今まで所々で覚えていた知識を体系的に学べる良い本でした。
図解が多くて書き方もわかりやすいのでサクサク読めますが、情報量は多く充実しています。OSやプロトコルの話からRFCの読み方の話まで書いている本ってなかなかないのでは。
利用頻度が高い基本的なコマンドも多く、かつ、実際にインフラエンジニアとして何を検討・対応するのかが書いてあるのも丁寧で嬉しかったです。
インフラの知識に自信がない方に是非お勧めできる一冊でした!

インフラエンジニアの教科書2 スキルアップに効く技術と知識

インフラエンジニアの教科書2 スキルアップに効く技術と知識

  • 作者:佐野 裕
  • 出版社/メーカー: シーアンドアール研究所
  • 発売日: 2016/08/26
  • メディア: 単行本(ソフトカバー)

『技術をつたえるテクニック』は書籍執筆前に読みたい一冊だった

@mochikoAsTechさんが書かれている「技術をつたえるテクニック ~分かりやすい書き方・話し方~」という同人誌が、書籍を書く前に本当に出会いたかった一冊でした。
書籍の執筆以外でも仕事やブログなどで文章を書く機会は多くあると思いますし、登壇に関してのノウハウも書かれています。
すぐにでも実戦で使えるテクニックが薄い本にギュッと詰まっていて、サクッと読めるけど学ぶことが多く、すごくオススメです!

booth.pm

📖 目次

  • Chapter1. 技術を文章で分かりやすくつたえる
    • 1.1 読者層をはっきりさせよう
    • 1.2 「すんなり入ってくる」ための工夫
    • 1.3 一度に沢山のことはつたわらない
    • 1.4 事実は時代とともに変わる
    • 1.5 分かりやすさを支える統一表記
    • 1.6 読者を迷子にさせないで
    • 1.7 できるだけ簡潔にしよう
    • 1.8 推敲は文章の品質を上げる
  • Chapter2. 技術を登壇で分かりやすくつたえる
    • 2.1 段取り八分現場二分
    • 2.2 前に立って話すときのテクニック
    • 2.3 つたえるときの心のあり方
  • Chapter3. 教わり上手をはじめよう
    • 3.1 分からないを正直に言うことこそ最初の一歩
    • 3.2 地蔵にならず反応を返そう
    • 3.3 おわりに

💬 感想

第1章では文章を書く上で、第2章では登壇をする上で、必要となる『テクニック』について書かれています。
本のタイトルにもある『テクニック』という言葉が内容にビッタリと合っていて、意識すれば明日から使える具体的なポイント / 注意点がたくさん書いてあります!
私も以前「いちばんやさしいGit&GitHubの教本」という書籍を書いたのですが、その時にレビューで指摘いただいた内容がとても盛り込まれていました…!くっ…!書籍を書く前に出会っていれば…!

syobochim.hatenablog.com

1.5.4 表記ゆれのチェックはツールでやろう

「いちばんやさしいGit&GitHubの教本」を書いた時にとても便利なツールを教えていただきました。それが「テキスト校正くん」というVisual Studio Codeのプラグインです。
このツールを使うと一般的なルールに基づいた文章チェック(「ですます」調と「である」調の混在など)や、設定した単語の表記ゆれのチェック(「サーバー」と「サーバ」)を自動で実施してくれます。
テキスト校正くん - Visual Studio Marketplace

「技術をつたえるテクニック ~分かりやすい書き方・話し方~」でも、ツールでの文章チェックを推奨しています。「テキスト校正くん」と同じような自動で文章チェックをしてくれるツールとして、Visual Studio Codeのプラグインの「vscode-prh-extention」が紹介されていました。
prh - ProofReadingHelper - Visual Studio Marketplace

「いちばんやさしいGit&GitHubの教本」は共著であり、二人の書き言葉の統一をするため、特に表記ゆれのチェックはとても助かりました。
そして、自分一人で書いた文章にも表記ゆれが本当にたくさんあったので、自動チェックまじで大事!!

1.7.1 「ということ」「することができる」は必要?

「ということ」「することができる」を使うと文章が冗長になるので、文章の並び順序を変更したり、冗長な部分を削除して簡潔な文章になるように意識しましょう。

細かいポイントですが、私は特にこの内容が響きました…。
私の書き癖として、「することができる」を無茶苦茶たくさん使ってしまっています…。そして、やはり書籍レビューでも指摘をいただきました。
例えば、以下のような感じ。

before

バイナリファイルでは、git diffコマンドでファイルの変更差分を確認することは出来ません。

after

バイナリファイルではgit diffコマンドでファイルの差分を確認できません。

レビューで指摘されて初めて、この書き方が冗長な表現だと認識しましたし、普段書いている文章にも多用してしまっているなうああ、と…。

💬 まとめ

自分が特に印象に残っている2つの内容を取り上げましたが、それ以外にも書いてあることの多くが実際に書籍レビューにて指摘されました。(なので、この本を読んでいると刺さる部分が多くて心が痛くなる…。w)
執筆前にこの本の内容をしっかり自分の中に落とし込んでいたら指摘数も変わっただろうな…。

そして、冒頭にも書きましたが、文章だけでなく登壇のテクニックについても書かれてあるので活かせるタイミングは多いのではないでしょうか。
この本に書いてあるテクニック自体はそれぞれがすぐに実践できる簡単なものが多いですが、自分の書き癖・登壇時の話癖ってあると思うので、繰り返しInputしたい一冊です。

あ、「【コラム】真面目な後輩に説明を聞いてもらえないのはなぜ?」も、「クゥ…!わかるぜ…!」という内容で面白かったです。

booth.pm