割れ窓理論

割れ窓理論について、「1枚の割れた窓が長期間修理されずに放置されていると、ビルの住人に投げやりな感覚が植え付けられ、2枚目の窓が破られたりゴミが撒き散らされたりと建物に対する深刻な破壊が起こり始まる」と本書で説明していました。

これはネガティブな考えには伝染性があるからだとされており、明らかに問題があるにもかかわらずその状況を無視することで、破滅に向かっていきます。

割れた窓は放置しない

割れた窓は、悪い設計や誤った意思決定、質の低いコードにも当てはまり、そのままにしておくことで深刻な問題を引き起こすことになります。

そのため割れた窓は発見と同時に修復する必要があります。もし正しく修復する時間がないのであれば、割りやすいところにその旨を明示するなど、何らかのアクションが必要です。

実体験としても割れ窓理論

たしかに実体験として振り返ってみても、この割れ窓理論は開発においても当てはまると思います。

最初は頑張ってテストを書いていたのに、ある時にテストがやりにくいコードを実装してからテストをしなくなったことで、バグが頻発しプログラムの依存関係が煩雑化するなど、みるみるうちにシステムが破壊に向かったことがあります。

後でやればいいやはたいてい後からやらないため、いっときの楽しようという考えが後々の自分の首を絞めることが多々ありました。

どんなにしんどくても割れた窓を見つけたら見て見ぬふりをせずにその場でしっかりと対応することが大切だと改めて実感させられました。

契約による設計(DbC)

DbC(Design by Contract)とは、ソフトウェアモジュールの権利と責務を文書化し、プログラムの正しさを保証するための簡潔かつパワフルな技法のことです。

ここでいうプログラムの正しさとは、要求された以上のことも、以下のことも行わないというものです。DbCを提唱したMeyerはDbCを実行する上で、以下の想定と確約を解説しました。

事前条件

この機能を呼び出す前に必要な要求のことを指します。事前条件に違反している場合には、この機能を呼び出してはいけません。そして、適切なデータを引き渡すのは呼び出し側の責任になります。

事後条件

この機能が終了した後にその機能を保証する内容のことです。事後条件があるということは、この機能が正常に終了することを意味しています。

クラス不変表明

クラスが呼び出し側に対して、常に真になることを保証する条件です。

コードのためのテスト

テストしやすいコード

ソフトウェア開発におけるコンポーネントベース開発によって、テストのしやすいコードを書くことができます。

初期の段階からソフトウェアの中にテスト機構を組み込んでおき、ソフトウェアを接続する前にテストができるようにしておくことが大切です。

契約に対するテスト

先程のDbCにあった契約が遵守されていることを確認するテストを用意しなければなりません。

これはコードが契約に合致しているのか、そして契約の意味が我々の考えている通りのものなのかをいう2つの意味を含んでいます。

DbCについて

DbCは最近になるまで知らなかったが、TDDを実践していく中でDbCという手法を学びました。本書を通してDbCについて理解を深めるきっかけになりました。

アジャイル開発用語

マスターストーリーリスト

プロジェクトでこなすToDoリストのことです。

ベロシティ

チームがユーザーストーリーを動くソフトウェアに変換する速度のことです。

イテレーション

一週間か二週間を全力疾走する短距離走みたいなもので開発期間を指します。

イテレーション数＝作業量の合計 / チームの予想ベロシティ

スコープを柔軟にする

スコープを柔軟にしておくことがアジャイルプロジェクトで計画を誠実なものに保ち続けるための秘訣です。

新しいストーリーを追加するときは、必ずどれかひとつ既存のストーリーをマスターストーリーリストから削ってもらう必要があります。これにより開発チームは顧客に要求変更の機会を提供しつつ、スコープをプロジェクトで作業できる範囲内に留めておくことができます。

マスターストーリーの長さを一定に保つ

アジャイル開発の原則として、要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、顧客の競争力を引き上げます。

この原則により、最初に要求を集めておかなきゃとは思わなくなり、ストーリーの無駄を減らすことができます。

さらに、マスターストーリーの長さを一定に保ち続けていくほうが望ましいとうことを、顧客と開発チームの両者が学んでいきます。

初回の計画作り

1. マスターストーリーリストを作る

マスターストーリーリストには顧客がソフトウェアで実現したものを載せていきます。

載せた項目は、顧客が優先順位をつけて、開発チームが見積もります。その結果が計画の土台になります。

良いマスターストーリーリストの長さは1ヶ月から6ヶ月程度の期間でこなせる仕事の範囲に収まります。

2. プロジェクト規模を見極める

プロジェクトの規模とこれから始めるプロジェクトの長さを見通します。プロジェクトはどのくらいの期間で終わるかを把握します。

3. 優先順位をつける

マスターストーリーリストにあるストーリーに優先順位をつけるのは顧客の仕事で、ビジネスの観点から優先順位をつけてもらいます。

そうすることで、投資に対して最も価値の高い成果を手に入れることができます。

しかし、開発チームにも果たすべき義務があります。具体的には、アーキテクチャ上のリスクを低減できるストーリーや顧客にとって価値があり、しかもアーキテクチャを検証できるストーリーなどです。

4. チームのベロシティを見積もる

プロジェクト開始時点でのチーム速度はどれくらいかなのかわからないため、最初はある程度推測する必要があります。

その後、チームベロシティはイテレーションを3、4回こなせばだんだん落ちついていき、チームの開発速度も検討がつくようになります。

チームベロシティは以下のように求めます。

チームベロシティ＝完了させたストーリーポイントの合計 / イテレーション数

5. 期日を仮決めする

プロジェクトの完了期日に対する作戦として、「期日固定」と「フィーチャセット固定」があります。

「期日固定」は、日付を特定して「プロダクトはこの日が来たら何がなんでもリリースします」と宣言する感じです。この作戦の場合、重要なストーリーが新たに見つかった場合、想定的に優先順位が劣るストーリーをスコープから外します。

「フィーチャセット固定」は、中核をなすフィーチャのまとまりに含まれるフィーチャを全て完成させるまでは作業を続け、日程を調整する作戦です。中核をなすフィーチャーセットを確実に揃えるためなら、スコープではなく期日が調整対象になります。

6. バーンダウンチャート

バーンダウンチャートはチームがどれぐらいの速度でストーリーを実装しているかをひと目でわかるようにした図のことです。チームの速度に加えて、この先いつ頃プロジェクトを完了させられそうかの見通しも立てられるようになっています。

バーンダウンチャートの縦軸は残っている作業の総量で、横軸は時間、具体的にはイテレーションを表します。あとはイテレーションごとの残作業量を記録して、図にプロットしていきます。

アジャイル計画をやってみて思ったこと

ここからは本書と関係ないが、自分自身アジャイル計画を始めてみて思ったことは、日々計画とやるべきタスクが明確で常にプロジェクトの進行を見通せることとてもスッキリした気分になります。

今までウォーターフォール開発やアジャイルもどきであったプロジェクトがどう転ぶのかわからないモヤモヤ感が全然ないです。その分、逐一ストーリーの見積もりやメンバー共有、緊急タスクがあった際のストーリーの見直しなど、アジャイル計画を実行するために必要な時間と労力は大きいと感じています。

もちろんその時間と労力をかけるほどの価値を感じており、アジャイル開発を実践できる環境にありがたみを感じています。

アジャイル計画は、ビジネス側と開発チームの両方がプロジェクトを円滑かつ適切に進めていくためにアジャイル開発の中でも特に重要な役割を担っていると思うようになりました。

アジャイルサムライ−達人開発者への道

サークルオブライフ

上の図はXPのプラクティスを描いた図で、アジャイルの本質を示した原型であり、最も典型的なものとなっています。

ビジネスプラクティス

最も外側にあるのが、ビジネス向けのXPプラクティスです。ビジネス側と開発チームの両方がプロジェクトをマネジメントするための原則を提供しています。

計画ゲーム

計画ゲームは、このリングの中心的な役割を果たします。これはプロジェクトを機能、ストーリー、タスクに分割する方法を示している。またこれらの機能、ストーリー、タスク見積り、優先順位付け、スケジューリングのガイダンスを提供しています。

ストーリーの作成

システムの機能をユーザーの視点から簡潔に記述したユーザーストーリーを考えます。

例)

車の運転手として、
アクセルペダルを強く踏みたい。
それは車の速度を上げるためだ。

この時、ストーリーの詳細化は避けます。ストーリを話し合うときに詳細を全て書き留めるべきと思いがちだが、そのような衝動を抑える必要があります。

ストーリーの見積もり

ストーリーの見積もりは見積もり時間ではなく、見積もり労力を単位とします。ログアウト機能は1ポイント、ログイン機能は3ポイントのようにポイント数を選択します。

イテレーション

イテレーションは一連の工程を短期間で繰り返す開発サイクルのことで、イテレーションプランニングミーティング(IPM)から始まり、期間の1/20の時間になるようにします。

各イテレーションの目標は、ストーリーを完成させてデータを生成することです。

ベロシティ

イテレーションの最後の作業は、ベロシティ(開発速度)とバーンダウンチャート(プロジェクトの進捗)の更新です。受け入れテストをパスしたストーリーのポイントだけをチャートに記録します。

小さなリリース

小さなリリースは、小さな単位で作業するようにチームをガイドします。

プラクティス

小さなリリースのプラクティスは、開発チームはできるだけ頻繁にソフトウェアをリリースすべきというものです。

受け入れテスト

受け入れテストは、機能、ストーリー、タスクの「DONE」の定義を提供します。明確な完成基準の設定方法をチームに示します。

プラクティス

受け入れテストのプラクティスは、ビジネス側がユーザーストーリーの振る舞いを形式的なテストで記述し、開発者がそれらのテストを自動化することです。

テストはイテレーションにおけるストーリーの完成の定義であり、ストーリーは受け入れテストをパスするまでは完成ではありません。

チーム全体

チーム全体は、ソフトウェア開発チームはプログラマー、テスター、マネージャーなどの様々な職種で構成されており、共通のゴールを目指してみんなで協力するものだという考えを示しています。

同じ場所

同じ場所にいるだけなのにチームの効率が劇的に向上するとされています。

家からのリモートも増えてきたが、同じスペースにいることによる雑談や即席のMTGなどが失われるため、偶発的な会話がなくなりがちです。

チームプラクティス

「サークルオブライフ」の中間のリングは、チームのプラクティスを示しています。これらのプラクティスは、開発チームがチーム内やマネージャーとコミュニケーションするためのフレームワークと原則を提供します。

持続可能なペース

持続可能なペースは、開発チームがリソースをすぐに消費してしまい、ゴールの手前で力尽きないようにするためのプラクティスです。

献身

残業したからといって、雇用主に献身的であることを示したことにはなりません。

すべての残業が悪というわけではないが、残業によってスケジュールが短縮されるよりも、残業にかかるコストの方が大きくなりやすいことを意識する必要があります。

共同所有

共同所有は、プロジェクトにおいてチームに「知識の断絶」が起きないようにするためのプラクティスです。

アジャイルプロジェクトでは、コードはチーム全体で所有しており、チームの誰もが全てのモジュールにいつでもチェックアウトして改善できます。

継続的インテグレーション

継続的インテグレーションは、チームが現在地を常に把握できるように、フィードバックループを何度も閉じることにフォーカスするプラクティスです。

継続的ビルドの規律

継続的ビルドは絶対に壊してはいけません。ビルドが壊れた時は緊急事態であり、全てのプログラマーは作業を中断し、すぐにビルドの復旧に取り掛かる必要があります。

メタファー

メタファーは、チームとビジネス側がシステムについてコミュニケーションするための語覚や言語を作成し、広めるためのプラクティスです。

チームが効果的にコミュニケーションするためには、製薬と規律を持つ用語や概念が必要になります。

ドメイン駆動設計

ドメイン駆動設計のなかにユビキタス言語という用語があり、これはメタファーのプラクティスに採用されるべき概念です。
チームに必要なのは問題領域のモデルであり、それを全員が合意した語彙(ユビキタス言語)で記述します。ここでいう全員とはプログラマー、QA、マネージャー、顧客、ユーザーを含めた全員です。

テクニカルプラクティス

「サークルオブライフ」の最も内側のリングは、最高の技術品質を保証するために、プログラマーをガイドおよび強制するための技術プラクティスを示しています。

テスト駆動開発(TDD)

テスト駆動開発は、技術チームが高品質を維持しながらすばやく進むための命綱です。

TDDの3つのルール

1. 失敗するテストを書くまではプロダクションコードを書いてはいけない
2. 失敗するテストを必要以上に書いていけない
3. プロダクションコードを必要以上に書いてはいけない

この3つのルールに従うことでデバッグの軽減、優れた低レベルのドキュメンテーション、楽しさ、完全性、分離といった様々なメリットがあります。

勇気

完全なテストスイート(ソフトウェアテストの目的や対象ごとに複数のテストケースをまとめたもの)があると、コードを変更する恐怖がなくなります。

コードをクリーンにする恐怖がなくなるため、コードをクリーンにするようになります。

システムを整理して秩序を維持できるようになり、システムの設計を損なうことがなくなります。

リファクタリング

リファクタリングは、すべての作成物の継続的な改善と改良を促進します。

リファクタリングによって振る舞いを変更することなく、システムの構造を改善します。

シンプルな設計

シンプルな設計、チームがムダなことをしないようにガイドするためのプラクティスです。

必要とされるコードだけを書いて、最もシンプルで、最も小さく、最も表現力のある構造を維持します。

設計のウェイト

設計が複雑になれば、プログラマーにかかる認知的負荷は大きくなります。この認知的負荷が設計のウェイトで、設計のウェイトが増えるほどシステムを理解したり操作するために必要な時間や労力が増えます。

シンプルな設計のゴールは、設計と機能の複雑さのバランスをとることであり、要求とのバランスを保ちながら、継続的にシステムの設計をリファクタリングしていきます。

ペアリング

ペアリングは、革新性と正確性を促進するレベルで、技術チームが知識の共有、レビュー、協力ができるようになるためのプラクティスです。

ペアになるプログラマーは異なる役割を担当します。ひとりがドライバーで、もうひとりがナビゲーターです。

ドライバーはキーボードとマウスを持ち、ナビゲーターは俯瞰的な視点でドライバーにアドバイスします。

ペアになるのは一般的に短時間で、多くの場合は1〜2時間以上は続かないです。

Clean Agile 基本に立ち戻れ

TDDのサイクル

テスト駆動開発は「レッド」「グリーン」「リファクタリング」のサイクルで回していきます。これは全てのストーリーの受け入れ条件を満たすまで繰り返します。

TDDにおいてまだ存在していなコードのテストを書くのに戸惑いますが、必要なコードがすでにそこにあるかのごとく書くことを意識すると良いみたいです。

レッド

新しいコードを書く前に、まずは失敗するテストコードを書きます。

新しいコードの意図をテストで示します。

グリーン

どんな方法でも良いのでテストが成功するコードを書きます。

素早くバーをグリーンに変えることが最優先になります。

リファクタリング

テストが成功する状態を維持しつつ簡潔・明快なコードにします。

持ち込んだ重複を取り除き、素早くグリーンになるようにします。

TDDのルール

失敗するテストを一つ書くまでは、新しいコードを一切書かない

テストを書くということは、追加しようとしているコードの価値について真剣に考えることになり、そうすることで凝りすぎた解決策に走ることを避けることができます。

ここで大事なのは、本当に必要なコード以外書いてはいけないということです。

危なっかしいところを全てテストする

TDDでは文字通り全てをテストするわけはなく、危なっかしいところを全てテストします。

いかにも壊れてしまいそうな箇所や特定の条件下で特殊な挙動をする箇所がある場合、そうした意図を伝えるためにテストを書きます。

テストを作成する

実際にテスト駆動開発入門を読みながらTDDを学びます。VSCodeにJavaの実行環境を構築し、実際にコードを書いてテストを実行していきます。

まずはテストを作成します。テスト駆動開発入門に則って5ドルを2回回すと10ドルと等しくなることをテストします。

・DollarTest.java

public class DollarTest {
  @Test

  public void testMultiplication() {
    Dollar five = new Dollar(5);
    five.times(2);
    assertEquals(10, five.amount);
  }
}

失敗することを確認する

テストを作成したら、まだ実装していないので当たり前ですがテストが失敗することを確認します。ここまでがTDDサイクルで言う「レッド」であるという認識です。

テストが通るように実装する

テストを作成し、失敗することを確認したら実際に処理を実装をしていきます。

・Dollar.java

public class Dollar {
  int amount;

  Dollar(int amount) {
  }

  void times(int multiplier) {
  }
}

シンタックス系のエラーはなくなりましたが、テスト結果が正しくありません。期待されている値は10ですが、0となっています。

期待されている値が10になるように実装していきます。

public class Dollar {
  int amount = 5 * 2;

  Dollar(int amount) {
  }

  void times(int multiplier) {
  }
}

テストが通りました。ここまでがTDDサイクルで言う「グリーン」であるという認識です。

リファクタリングする

テストが成功したといえど、amountの初期値を10にしているため引数の値が変わればテストが失敗します。そのため、どんな値でも対応できるようにリファクタリングをしていきます。

public class Dollar {
  int amount;

  Dollar(int amount) {
    this.amount = amount;
  }

  void times(int multiplier) {
    amount *= multiplier;
  }
}

リファクタリングをしたら再度テストを実行し、テストが成功することを確認します。

コンピューターウイルスとは

一口にコンピューターウイルス(以下ウイルス)と言っても定義は曖昧だが、一般には悪質なソフトウェア全般を指すことが多いです。情報を盗み出したり、外部から遠隔操作できるようにしたり、金銭を奪うするソフトウェアは全てウイルスと言えます。

ウイルスはその仕組みや働き、プログラムの構造などから、様々な名前がつけられています。

・情報を盗む

スパイウェア：個人情報などを外部に送信する

キーロガー：キーボードの入力情報を外部に送信する

・遠隔操作できるようにする

ダウンローダー：攻撃者が用意した別のウイルスに感染させる

ボット：攻撃者の指示を受けて情報を盗み出したり、第三者を攻撃したりする

・金銭を奪う

ランサムウェア：ユーザのデータを暗号化し、元に戻すために金銭を要求する

マイニングウイルス：パソコンのリソースを使って仮想通貨を得るための計算を実行する

ウイルスの感染場所

ウイルスの感染場所は大きく3つに分類できます。

1. 既存のファイルへの埋め込み
2. 新しいファイルとしての追加
3. メモリ空間への追加

既存のファイルへの埋め込み

このタイプは、既存のファイルを上書きしたり、一部を書き換えたりすることで感染します。既存のファイルは、ユーザが普段利用するプログラムファイルだったり、Officeの文書ファイルだったりします。

プログラムファイルに感染した場合は、ユーザが起動したり、OSの起動シーケンス中に実行されることで、ウイルスが活動開始します。

一方、オフィススイートの文書ファイルの場合は、マクロと呼ばれる機能によって、文書ファイルが開いたときにウイルスが活動開始します。

新しいファイルとしての追加

このタイプは、パソコンに全く新しいファイルとして入り込むウイルスです。

有益なソフトウェアに見せかけて、ユーザ自身にインストールさせることが多いです。

メモリ空間への追加

このタイプは、メモリ空間に存在し、コンピューターを再起動すれば消えてしまいます。だが、シャットダウン時にレジストリなどOSのシステムファイルに書き込まれて、再起動時に再びメモリ空間に置かれるタイプもあります。

ディスクにファイルを保存しないため、どのタイプよりもウイルス対策ソフトで検知されにくくなります。

ウイルスに感染する経路

引用：これ1冊で丸わかり 完全図解 セキュリティー入門

ウイルスに感染する経路は主に「メール(添付ファイル)」、「Webアクセス」、「ファイルのダウンロード」、「LAN」、「USBメモリ」の5種類に分けられます。

基本的に感染経路として最も多いのはメールでからだが、2017年4月に発生したWannaCryが大流行した際はネットワーク経由が最も多くなっています。ここでのネットワークはWebアクセスとLANによる感染経路がまとめられています。

WannaCryとはなんだったのか

2017年5月に世界的に大発生したワーム型ランサムウェアであるWannaCryが話題になりましたが、これは一体どんな仕組みで何が起こっていたのか本書で語られていました。

ランサムウェアでありワームであるWannaCry

WannaCryは感染したパソコンのファイルを暗号化し、複合のための身代金を要求するランサムウェアであると同時に感染拡大機能を備えるワーム面も持ちます。

感染拡大の際にWannaCryが悪用したのが、Windowsでファイル共有などに利用されるSMBという機能が抱えていた脆弱性です。

マイクロソフトは2017年3月にこの脆弱性を対処するための更新プログラムを公開しましたが、WannaCryに感染したのは、この更新プログラムを適用していないWindowsパソコンでした。

WannaCryが感染を広げる仕組み

引用：これ1冊で丸わかり 完全図解 セキュリティー入門

WannaCryは攻撃対象のパソコンにまずポート445で接続します。ポートが開いていなければWannaCryには感染しません。

WannaCryが攻撃対象に接続すると、まずSMBの脆弱性があるかどうかをチェックします。脆弱性がある場合は、侵入口を作るためのプログラムであるバックドアを送り込み、WannaCry本体を送り込んで感染させます。

感染拡大能力を得た「EternalBlue」と「DoublePulsar」

引用：これ1冊で丸わかり 完全図解 セキュリティー入門

元々感染拡大能力が低かったWannaCryは「EternalBlue」と「DoublePulsar」の2つのツールを取り込むことで、ネットワークを介して急速に被害が拡大しました。

DoublePulsarはWannaCryが悪用するバックドアで、EternalBlueはSMBの脆弱性を悪用することで、DoublePulsarを設置するプログラムです。

これらのツールはハッカー集団「Shadow Brokers」がアメリカのNSAから盗み出したツールを悪用して凶悪化したものでした。

WannaCryの仕組み

引用：これ1冊で丸わかり 完全図解 セキュリティー入門

まずEternalBlueを使って、攻撃対象のパソコンのメモリにあるSMBドライバにバックドアのDoublePulsarを送り込みます。

DoublePulsarを仕込まれたメモリ上のSMBドライバは、Isass.exeというシステムファイルのプロセスに対し、WannaCryを含むDLLをインジェクションします。

DLLはプログラムに実行時に動的にリンクさせるライブラリのことで、DLLインジェクションすることで、プロセスに強制的に指定したDLLファイルを注入し、プロセスを本来とは違う動作をさせます。

今回の場合、Isass.exeのプロセスにDLLインジェクションされることで、WannaCryが起動し、暗号化・身代金要求と他のパソコンへの感染拡大を開始します。

これ1冊で丸わかり 完全図解 セキュリティー入門

排他制御

共有資源に対して複数トランザクションからの操作が見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションから共有資源にアクセスしている時は他のトランザクションからはアクセスできないように直列に処理されるようにする制御のこと

つまり、システムを複数の利用者が同時に操作するような場合に、一貫して処理するために必要な制御機構が排他制御です。データの一貫性を保証する必要のある範囲(業務トランザクション)を検討し、その範囲で排他制御します。

例えばチームで共有して編集しているファイルがあったとして、メンバー同士で同時に編集してしまった場合データ不整合が起きてしまいます。そのような事態を防ぐために、あるメンバーがファイルを編集している時は、他のメンバーはそのファイルを編集できないようにする仕組みが必要です。Excelファイルの共有ではファイルごとやセルごとで排他制御を行、データ不整合を防いでいます。

楽観ロックと悲観ロック

楽観ロックは処理の終了時、悲観ロックは開始時に競合を検知するイメージです。実際は以下のようなタイミングでロックをしています。

• 楽観ロックは、ロックキー比較時
• 悲観ロックは、ロック状態確認時
• 行ロックは、ロックSQL発行時

楽観ロック

楽観ロックとは、他の操作による同時更新はよほどの限り起きないであろうという楽観的な前提の排他制御のことです。

楽観ロックでは「ロックキー」を使います。楽観ロック対象のデータにロックキーという属性を設け、データを更新するたびにロックキーを変更します。業務トランザクション開始時点と終了時点でロックキーの内容が変わっていなければ、他の操作でデータが更新されていないと判断できます。

楽観ロック対象データの何をロックキーとするか

ロックキーとしてよく候補になるのは「バージョン」と「タイムスタンプ」です。

• 「バージョン」の場合は、データを更新するたびに数値を加算し、その数値を比較します。
  → 更新したら1→2のようにインクリメントするイメージ
• 「タイムスタンプ」の場合は、データを更新するたびに更新時刻を上書きし、その時刻を比較します。
  → updated_atのようなカラムを用意し、更新時刻を上書きするイメージ

タイムスタンプはデフォルトのテーブルで持っていたりするので、新たにカラムを追加せず採用しがちですが、ロックキーとして「バージョン」を推奨します。なぜなら「タイムスタンプ」は秒単位までしから保有していない場合、同一秒に複数の操作でデータを更新されると楽観ロックの判断ができなくなり、データ不整合が発生します。

それに対して「バージョン」は、更新時に単純に加算される数値であるため、十分な桁数を持っておけば、複数の操作で同一値になることはないからです。

楽観ロックは同一データの更新頻度が高い時は適さない

楽観ロックは業務トランザクションの終了のタイミングで排他制御を実現する方法であり、操作が終わるタイミングではじめて他の操作による更新があったことがわかります。楽観ロックは実際のシステムによく採用されますが、同一データの更新頻度が高いケースには適さず、代わりに悲観ロックが採用されます。

悲観ロック

他の操作による同じデータの変更が頻繁に起こるであろうという悲観的な前提の排他制御のことです。業務トランザクションの開始のタイミングで排他制御を実現します。

悲観ロックは、ロック対象のデータにロックしているユーザとロック状態を表す属性を設けます。同一ユーザによる複数端末からの同時ログインを許容しているようなシステムでは、セッションIDのようにどの端末からのアクセスかを識別できる情報も必要です。

悲観ロックの仕組み

業務トランザクションが始まると、データのロック状態を参照し、他のユーザによってデータがロックされていないことを確認します。他のユーザによってデータがロックされていた場合、悲観ロックによるエラーが発生し、業務トランザクションを終了させます。誰もデータをロックしていないことを確認できたら、データのロック状態を更新し、ロック中にします。

このように悲観ロックはデータのロック状態を参照してからロック状態を更新するまでの間、他の操作によるデータ更新が行われないようにします。

ロックを開放するタイミングが難しい

悲観ロックは業務トランザクションの開始時点でデータをロックして排他制御を実現する方式であるため、終了したタイミングで確実にロックを開放しなければ、誰もそのデータを更新できなくなります。業務トランザクションが終了するタイミングは一つではなく、システムからのログアウト、異なる画面への遷移、ブラウザを閉じるなど様々な事態を想定してロックを開放することが必要になります。さらにシャットダウン、セッションタイムアウトなどの操作はアプリケーション設計で完全防ぐことはできません。

そのため不測の事態に備え、管理者の場合ロック開放できるような機能や長時間ロックされているデータをロック開放する機能を設けるなど、ロック済みのデータを開放する仕組みが必要となります。

バッチ処理とオンライン処理を共存させる排他制御の考え方

鳴くまで待とうホトトギス方式

バッチ処理の対象となる全データをDBのロックメカニズムでロック(ここでいう行ロック)できるまで実行するという考え方です。行ロックを取得してしまえば、行ロックを解放するまで他のトランザクションでそのデータを更新することはできません。そのため、オンライン処理がロック開放されるまで待つしかありません。

殺してしまえホトトギス方式

バッチ処理を優先し、オンライン処理のロックを奪い取るという考え方です。バッチ処理対象のデータに対して、ロック状態にかかわらずバッチ処理でロック状態を上書きしてしまえば、オンライン処理のロックを奪い取ることができます。ただし、バッチ処理中のデータロックが奪われるとバッチ処理を正しく処理できないため、バッチ処理中のデータは管理者の操作による強制的なロック開放ができないようにするなどの考慮が必要です。

鳴かせてみせようホトトギス方式

オンライン処理を優先し、バッチ処理側はロックできたデータのみを処理対象とするという考え方です。オンライン処理で行ロックされているデータは処理対象としないため、データごとに「FOR UPDATE句」で行ロックを取得する必要があります。タイミング悪くバッチ処理中にオンライン処理データをロックしていると、次回のバッチ処理のタイミングまでそのデータを処理できないことになるため注意が必要です。

参考：トラブル知らずのシステム設計 エラー制御・排他制御編

学びのサイクル

学びのサイクルは「情報収集・モデル化・検証」の3要素の繰り返しです。

学びのサイクル① 情報収集

情報収集は箱を集めるイメージです。たくさんの箱(情報)を集めて並べていく作業で、この段階では積み上がりません。

知りたいところから学ぶ

前提条件

• 目標が明確化されている
  → 〇〇を勉強する・マスターするでは不明確。〇〇の血画について検索して読むのように明確化する
• 目標が達成可能である
  → 達成方法がわからない目標はたどり着けない。達成可能な適切な目標を決める
• 大まかに全体像を把握している
  → 必要な情報を見つけるためにどこを探せば良いのかがわかる必要がある

大雑把に

狭い一部分だけを詳細に見るのではなく大雑把に全体を見ると、何か必要なものを探そうとしたときに絞り込むことができるようになります。具体的に以下のような方法があります。

• 目次や見出しをチェックする
• ディレクトリ構成を読んだりデータ構造を知る
• ドキュメントや論文の大まかな構造

学びのサイクル② モデル化・抽象化

モデル化・抽象化は箱を積み上げていくイメージです。情報収集によって集めた箱を土台とし、その上に一つずつ積み上げてることで、高みを目指します。抽象的とは高い位置にあること、具体的とは低い位置にあることを指します。

上に積む箱は、収集したものに限らず、考えることによって自分で作り出すこともあります。この新しい箱を自分で作り出すこと、つまり抽象的な知識を作り出すことがモデル化です。

比較して学ぶ

同じと違うの間に注目

新しい気づきのためには、同じでも違うでもない、一部同じで一部違うもの同士を比較する必要があります。

上図のように「違っている」、「なぜ違っているのか？」、「〇〇の視点で考えると違っていない」などのサイクルを回すことで、一歩一歩階段を上がるように考えを進めていくことができます。

歴史から学ぶ

歴史から学ぶことは今と昔の比較で、共通のパターンを見つけることで次に何が起こりそうかを予想できます。またどう変わったのか、なぜ変わったのかを考えることで理解が深まります。

学びのサイクル③ 実践・検証

箱で例えると実践・検証は奥行き方向に並んでいます。正面からは最終的な成功したやり方の箱だけ見えるますが、実はたくさんの試行錯誤の末にできています。

作って検証

正しく理解できているどうかは、理解をもとに何かを作ってみて、それが期待通りに動くかどうかで検証できます。プログラミングなら自分で書いて実行し、正しく理解できていない場合はエラーになります。そしてエラーになったプログラムを修正して実行するなど検証できます。

解説ブログ記事を書くのも作ることの一種です。新しいことを学んだら「1日前の自分にどう説明するか？」を考えて解説すると理解が曖昧なところがわかります。

タスク処理

全部集めてそのあとで処理する

Getting Things Done(GTD)の手法を使います。GTDでは気になることを全部一か所に集め、やるべき子を覚えておかないといけないというストレスから開放します。その後書き出したタスクを実行します。このように収集フェーズと処理フェーズにわけることが大事です。

重要事項を優先する

緊急、重要の4つの領域に切り分けてタスクの優先順位を決めていきます。

実際にタスク管理ツールとしてTrelloを使っていますが、上の2つのポイントを押さえているため有効なツールだと再認識しました。

タイムボックス

大きすぎるタスクを小さく刻む手軽な方法が時間を切ります。タスクに合わせて時間を決めるのではなく、時間を固定する手法を「決まったサイズ(時間)の箱にタスクを入れる」というイメージでタイムボックス化と言います。

このタイムボックスの考え方を個人のタスク管理に応用したのがポモドーロテクニックです。25分を1ポモドーロとし、25分集中したら5分休みます。これを続けることで、あるタスクが1ポモドーロ(25分)で終わるのか、4ポモドーロかかるのかなどの見積もり力も鍛えることができます。

自分経営戦略

何を学ぶかを決めることは、時間やお金、やる気などの限られた資源を何に投資するか意思決定することです。

拡大再生産戦略

拡大再生産戦略とは仕事を効率化することで時間の余裕を作り、その余裕を新たな学びに投資することです。以下の3つの要素から成り立ちます。

• 知識を使って時間を得て、その時間を知識獲得に投資する
• 知識を使ってお金を得て、そのお金を知識獲得に投資する
• 知識を使って立場を得て、その立場を知識獲得に投資する

差別化戦略

T型やπ型と呼ばれる専門性の深さと幅広い専門性を兼ね備えた人材は今後価値が高まります。効果的な戦略として、連続スペシャリスト戦略と呼ばれるある分野の専門性を獲得し、その専門性を活かして異なる分野へ参入し、そこで新しく専門性を獲得します。

前に読んだエンジニア成長戦略でもπ型人材の話は出ていました。個人的にこの自分経営戦略は納得がいくし特にエンジニアではある程度先を見据えて戦略的にキャリアを積むことがとても大切だと感じます。

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする

仮想化とは

仮想化とは、実体のないものをあたかも実現しているかのごとく表現する技術のことです。例えばある一台の物理的なサーバ上に、複数の仮想的なサーバを構築することができます。このように仮想化によって、物理的なサーバを増やすことなくサーバを増減できます。

逆に、仮想化によって実際は複数の物理的なサーバで構成されているのに、ユーザには1つのサーバに見せかけることも可能です。

仮想化にはサーバ仮想化、ネットワーク仮想化、ストレージ仮想化など様々な種類があります。

サーバ仮想化とは

サーバ仮想化とは、物理サーバ上に仮想的なサーバを構築する技術のことです。サーバ仮想化には「ホストOS型仮想化」、「ハイパーバイザ型仮想化」、「コンテナ型仮想化」があります。

• ホストOS型：物理サーバいインストールされたホストOS情で仮想サーバを動作させる
• ハイパーバイザ型：ホストOSなしで動作するハイパーバイザと呼ばれる仮想化ソフトウェアを利用する
• コンテナ型：コンテナというアプリケーションと実行環境をまとめて隔離する仕組みを利用し、OS単位ではなくアプリケーション単位で仮想化する

サーバ仮想化メリット・デメリット

仮想化として最もイメージしやすいホストOS型仮想化におけるメリット・デメリットは以下のことが挙げられます。

サーバ仮想化メリット

基本的に障害に強い

仮想サーバごとバックアップすることが可能なため、仮想サーバに障害が発生した場合でも、以前のバックアップから簡単に復元することが可能です。

コピーや削除、スペックの変更が容易

仮想サーバはデータなため、CPUやメモリなどを必要に応じて増減させて、スペックを変更することができます。またコピーや削除も容易です。サーバの性能を上げるためにサーバそのもののスペックを増強することを「スケールアップ」、サーバの台数を増やすことを「スケールアウト」、減らすことを「スケールイン」といいます。

サーバ仮想化のデメリット

物理サーバに障害時に仮想サーバに影響が出る

物理サーバに障害が発生すると、そのサーバ上で稼働している全ての仮想サーバに影響が出る場合があります。

コストが高くつく場合がある

小規模サービスや障害発生時の業務インパクトが小さいシステムでは、仮想化にかかるコストが高くつく場合があります。提供するサービスとの費用対効果を仮想化の導入前に検討することが必要です。

Dockerとは

Dockerとは、コンテナの実行やコンテナイメージの作成・配布を行うためのプラットフォームです。Dockerはアプリケーションを実行環境ごとパッケージ化するため、開発環境でも運用環境でも同じようにアプリケーションを動させることができます。

DockerはホストOSがLinuxであることを前提につくられており、ホストOSがWindowsやMacOSの場合はDockerのソフトウェアをインストールすることで、コンテナ型仮想化ソフトウェア上にLinuxの仮想マシンが構築されます。コンテナはその仮想マシン上で動作するという構成になっています。

Dockerのコンセプト

• 柔軟性：プログラミング言語などが制約されない
• 疎結合：システムを独立したコンポーネントへ分解できる
• 軽量：効率的にリソースを活用する
• スケーラブル：必要に応じてリソースを増減できる
• ポータブル：異なる実行環境への移行が容易
• セキュア：コンテナ同士分離できる

コンテナとは

コンテナはOS上で実行されているプロセスです。プロセスは実行中のプログラムのことで、コンテナが通常のプロセスと異なる点は、名前空間などの仕組みによって他のプロセスから隔離されるように設定されていることです。そのため、コンテナを使うことで外部から影響を受けない独立した環境でプロセスを実行できます。

コンテナイメージとは

コンテナイメージとは、コンテナを実行するためのテンプレートです。コンテナは、コンテナイメージから生成されます。コンテナイメージとコンテナの関係はオブジェクト指向的にいうと、クラスとオブジェクトの関係に似ています。コンテナないのプロセスの実行環境はコンテナイメージによって決まりますが、コンテナイメージ内でプロセスを事項されることはありません。

コンテナイメージの作成は多くの場合、コンテナの作成手順を記述したファイルであるDockerfileを使用して自動で作成します。

コンテナのライフサイクル

コンテナには作成や削除といったいくつかの状態があり、作成から削除までの状態の流れをコンテナのライフサイクルといいます。Dockerでは、コンテナの状態として主に「作成」、「実行」、「停止」、「ポーズ」、「削除」の5つがあります。

1. 作成：コンテナレイヤーが作成された状態
2. 実行：コンテナ内でプロセスが実行している状態
3. 停止：コンテナ内でプロセスが終了している状態
4. ポーズ：コンテナ内でプロセスが一時停止している状態
5. 削除：コンテナレイヤーが削除された状態

基本は1コンテナに1プロセス

コンテナは本質手にはプロセスと同じであるため、同じプロセスに含んだ場合に自然かどうかを基準に判断することができます。例えば、WebシステムにおいてWebサーバ、APサーバ、DBサーバの三層でシステムを構成するとき、1つのコンテナ内で3つのプロセスを実行するとも可能だが、通常別々のプロセスとして実行されるため、3つのコンテナに分けた方良いということになります。

参考：図解即戦力 仮想化&コンテナがこれ1冊でしっかりわかる教科書

スケールアップとスケールアウト

コンピューターシステムの性能を向上させるには2つの方法があります。1つ目はより優れたハードウェアを導入するスケールアップ、2つ目はハードウェアの数を増やすスケールアウトという方法です。どちらの方法を選択するかは時と場合によります。

スケールアップのメリット

• システムを単純にできる
• ソフトウェアの変更が必要ない

スケールアップのデメリット

• 高性能のハードウェアを導入するため高価である

スケールアウトのメリット

• 必要に応じて数を増やせる
• スケールアップと比べてコストを抑えられる

スケールアップのデメリット

• 複数のソフトウェアを想定した設計が必要

→ 正しく設計しないと数だけ増やしても性能が上がらない

Googleが選択した方法

検索エンジンの性質上、いくらでもコピーすることが可能なシステムであり、複数のハードウェアを用いることが可能でした。そのため、Googleではハードウェアはなるべく安価で普及しているものを使いつつ、その性能を十分に引き出すソフトウェアを自分たちで作る方法を選びました。

つまり普段我々が使ってるようなPCを大量に使い、世界規模の分散コンピュータシステムを作り上げていきました。

分散システムの構成

先ほど書いたようにGoogleでは世界規模の分散コンピュータシステムを作り上げており、ラックを1つの単位としたクラスタが複数あるデータセンターを各地に配置しています。

ラック

システムの基本となるのがラックです。1つのラックに40〜80台相当の部品が組み込まれています。ラックないのマシンはLANで結ばれ、ネットワークを通して互いに通信できます。

クラスタ

ラックを1つの単位として、それが多数結びつくことでクラスタが作られます。クラスタとは互いに協調して動作することで1つの機能を提供するコンピュータの集まりです。

データセンター

データセンターには1つまたは複数のクラスタがあるものとされています。Googleはこのようなデータんセンターを世界各地に分散配置しています。

Googleのソフトウェア開発

Googleの開発文化の中で気になったものをまとめました。

選ばれたプロジェクトだけが残る

Googleでは仕事は与えられるものではなく、自分で見つけるものであるようです。開発者は数あるプロジェクトから選ぶか、自分で新しいプロジェクトを提案することになります。魅力のないプロジェクトは開発者に選ばれることなく自然淘汰されるような仕組みになっています。

少人数のプロジェクトチーム

1つのプロジェクトは2〜6人程度の少人数チームで構成されています。大きなプロジェクトでも小さなプロジェクトに分割されます。チーム内で密にコミュニケーションをとりながらプロジェクト進めるようです。

20%ルール

全ての開発者は担当プロジェクトとは別に、就業時間の20%を普段とは違う新しいことに取り組むことが求められます。新しいことにも手を出すことで視野を広げようというのがその目的であるようです。

PRG(POST/Redirect/GET)パターン

Webブラウザの戻る対策の1つとしてPRGパターンがあります。これは登録処理(POST)と画面遷移(Redirect/GET)に分ける方法です。

登録処理(POST)を行った後、登録完了画面へのリダイレクトのレスポンスを返すことで、登録完了画面にGETリクエストを発行します。

セキュリティ対策として

POSTリクエストの内容がブラウザの履歴として記録されないため、送信した内容をブラウザの履歴がたどることを防止しています。そのため実装コストはかかりますが、PRGパターンは二重送信抑止、セキュリティ対策の点で効果的な手法です。

ただ、二重送信抑止として完璧ではなく、Webブラウザの戻る対策としては効果的であって、例えばヒストリバックから登録画面まで遡って表示した場合、登録ボタンをクリックすることで登録処理(POST)が行われてしまいます。つまり、二重送信を完全に防いでいるわけではありません。

モーダルとモードレス

別ウィンドウを使用して異なる画面を表示する「子画面遷移」という方式があります。

この子画面には親画面を見たり操作したりできない「モーダル」と子画面を表示している時でも親画面を見たりそうしたりできる「モードレス」の2種類があります。

セッション方式とHidden方式

モーダルやモードレスのように複数画面に分ける場合、前の画面で入力したデータの内容を後続画面に引き継ぐことが必要です。一時的なデータ保持方式として「セッション方式」と「Hidden方式」があります。

セッション方式

セッション方式は、Web・APIサーバでユーザセッションごとに管理しているメモリ領域を使用してデータを格納する方法です。注意点は、Web・APIサーバのメモリを消費するので、同時接続のユーザ数や同時画面起動数が増えるとメモリ使用量が大きく変動し、アウトオブメモリ(OOM)のリスクが高まります。

また、モードレスの場合はセッション管理をしっかり行わないと、複数の画面から同一のメモリ領域を更新してしまい、セッションの上書き問題が起きてしまうため注意が必要です。

Hidden方式

Hidden方式は、HTMLのinputタグのType属性をhiddenに指定し、画面に入力したデータをHTML文に含める方法です。注意点は、データ量が多いとブラウザとサーバ間の通信量が増大し、遅延の原因になることです。

また、ブラウザの開発者ツールなどを使用してhiddenの内容を編集できてしまいます。そのため、暗号化するなどの不正改ざんを防ぐ対策が必要です。

インデックスが性能を大きく左右

DBの実行計画

DBの実行計画とは、発行されたクエリを実行するための手順書のことです。対象のテーブルからのデータ取得方法や結合方法などが書かれています。

そのためSQLのパフォーマンスは実行計画によって大きく左右されます。実行計画を確認しインデックスを貼ることでパフォーマンスを向上することができます。

MySQLで実行計画を確認するには

ちなみにMySQLで実行計画を確認するにはEXPLAINステートメントを使います。クエリの先頭にEXPLAINをつけることで実行計画を確認することができます。実行結果のそれぞれの項目がどのような意味なのかは以下の記事が参考になります。

テーブルフルスキャンとインデックススキャン

大量のデータが格納されているテーブルをフルスキャンすると多大なコストがかかります。フルスキャンを避ける手法がインデックススキャンです。インデックスとは索引のことで、書籍などの索引と同じ考え方です。

DBは一定サイズのデータブロックにデータが格納されており、テーブルフルスキャンでは全てのデータブロックを読み取ります。インデックスを使うとダイレクトにデータブロックを特定できます。

トラブル知らずのシステム設計