1. パターン
1.1. インフラデザインの原則
1.1.1. リソースを抽象化して使う
1.1.1.1. サービス化する
1.1.1.1.1. インスタンスの役割に応じてミドルウェアやソフトウェアをセットアップして抽象化する
1.1.1.1.2. 例
1.1.1.2. 家畜化する
1.1.1.2.1. ansibleやchefを使って設定をコード化、自動する
1.1.1.2.2. クラスタ管理ツール下の１ノードとして扱う
1.1.2. 計算資源とストレージを分離する
1.1.2.1. 計算する環境とデータが存在する場所は独立しているという前提でハードウェアとソフトウェアを設計する
1.1.2.2. ハードウェア
1.1.2.2.1. 不足している資源を独立して追加したり、置き換えできる
1.1.2.2.2. ストレージの容量追加や可用性の向上は比較的安価で容易なので、分離によってデータ保持に集中しやすくなる
1.1.2.3. ソフトウェア
1.1.2.3.1. 同様の環境間での移設(サーバ間やHWの交換)や、異なる環境(HDDからオブジェクトストレージへの移行など）移行が容易になる
1.1.2.3.2. テスト環境のセットアップがしやすくなり、テストコストを下げたり、設計変更が決断できるようになる
1.1.3. 役割が異なる機能を同じインスタンスに混在させない
1.1.3.1. ワークロード、可用性が異なる役割を同じインスタンスに混在させるとメンテナンスや保守性が損なわれる
1.1.3.2. 複数の役割があると移行やバックアップが複雑になる
1.1.3.3. 可用性の要件が異なるとメンテナンス時間の調整が難しい
1.1.3.4. ワークロードが異なるとCPU、メモリ、 ストレージの不足やボトルネックの解析や解消が難しくなる
1.2. ネットワーク
1.2.1. インフラを変更せずにネットワーク境界を超える
1.2.1.1. 概要
1.2.1.1.1. ネットワークのセキュリティや制約をソフトウェアで迂回することで利便性を損なわない
1.2.1.1.2. Cloud VPNやSSHトンネリングを活用して、クローズドなネットワークにアクセスする
1.2.1.2. コンテキスト
1.2.1.2.1. プライベートなネットワーク内にあるデータベースやサーバに、デスクトップから同じネットワーク内にあるかのようにアクセスして 使い慣れたツールを使ったり、作業を自動化したい
1.2.1.2.2. ネットワーク全体のセキュリティレベルは下げずに利便性を追求する
1.2.1.2.3. 例
1.2.1.3. 実装
1.2.1.3.1. Cloud VPN
1.2.1.3.2. SSHポートフォワード
1.2.1.3.3. Ondemand bastion
1.2.1.4. メリット
1.2.1.4.1. 少ない手間、費用で環境をセットアップできる
1.2.1.5. デメリット
1.2.1.5.1. 物理的なネットワークに比べて、帯域やCPUパワーなどパフォーマンス上の懸念がある
1.2.1.5.2. セットアップや使い方に知識が必要
1.3. データの管理
1.3.1. リポジトリ上のマスターファイル
1.3.1.1. 概要
1.3.1.1.1. 頻繁に変更されるマスタデータはWebやファイルサーバ上に準備しておく
1.3.1.1.2. 対象データがすでにRDBMS上にある場合でも、 変更が頻繁にあるデータはあえて編集しやすい形式で保存しておく
1.3.1.1.3. プログラムやDBはフォーマットやストレージの異なる データを読み取って処理を行う
1.3.1.2. コンテキスト
1.3.1.2.1. 頻繁に変更する小規模なデータがある
1.3.1.2.2. 例
1.3.1.3. メリット
1.3.1.3.1. DBなどを使えなくても変更などの作業ができる
1.3.1.3.2. 作業のためにソフトウェアのセットアップなどが必要ない
1.3.1.4. デメリット
1.3.1.4.1. 運用方法の共有やドキュメント化が必要
1.3.1.4.2. RDBMSの外部キー制約などが使えない
1.3.1.4.3. プログラムやRDBMSで複数のデータソースに対応が必要
1.3.1.5. 実装
1.3.1.5.1. サービス
1.3.1.5.2. フォーマット
1.3.2. システム境界上の共有ストレージ
1.3.2.1. 概要
1.3.2.1.1. データセンターやクラウド環境 などの外部ネットワークと社内のネットワークの境界にストレージを設置し、様々な用途に利用する
1.3.2.1.2. ユーザーが作業するための手段(SSH, RDP）とデータを転送するための手段を分けて考えて、適切な手段を提供する
1.3.2.1.3. データ転送以外にもバックアップや、成果物の保存、共有にも利用する
1.3.2.2. コンテキスト
1.3.2.2.1. アドホックな分析やセットアップなどのために、物理的に離れたネットワークやセキュリティレベル の異なるネットワークの境界を越えてファイルをやりとりする
1.3.2.2.2. ファイルの転送、保存、共有のためにセキュアで信頼性の高いストレージが必要
1.3.2.3. メリット
1.3.2.3.1. サイズが大きなデータの転送が安全、確実、高速に行える
1.3.2.3.2. SFTPやS3互換APIなどセキュアで広く実装されているプロトコルを使うことで、自動化や標準化が容易になる
1.3.2.3.3. 監査やアクセス制御が行える
1.3.2.3.4. サービスや顧客を問わず共通のインフラとすることで個別に購入、メンテナンスするよりもコストが下げられる
1.3.2.4. デメリット
1.3.2.4.1. 運用やサイジングなどに中期的な計画が必要
1.4. 分析データの準備
1.4.1. データ分析向きのリッチなデータフォーマット
1.4.1.1. 概要
1.4.1.1.1. parquetやavroなどデータ分析フレームワーク向けに作られたデータ形式を使うことで、サイズが小さく、リッチな情報を含むファイルでデータを扱える
1.4.1.2. メリット
1.4.1.2.1. 統一されたフォーマットなので、デリミタや文字コードなどの詳細を気にしなくて良い
1.4.1.2.2. ファイル自体にスキーマなどのメタデータを含んでいるのでデータ自体に集中できる
1.4.1.2.3. サイズが小さく、ストレージサイズを節約したり、IO削減によってパフォーマンスが向上する
1.4.1.3. デメリット
1.4.1.3.1. ファイルの内容を簡単に確認できない
1.4.1.3.2. 対応しているソフトウェアがHadoop関連のものに限られる
1.4.2. お家が一番
1.4.2.1. 概要
1.4.2.1.1. データの発生元やサーバ上ではなく、ツールや分析環境や整った環境にデータを持ってきて作業を行う
1.4.2.1.2. 慣れないツールの学習コストや、パフォーマンスが貧弱だったり、制限がある環境を使うことによる非効率を避けるために工夫をする
1.4.2.1.3. 実装
1.4.2.1.4. メリット
1.4.2.1.5. デメリット
2. プラクティス(書きかけ)
2.1. RDBMS
2.1.1. ワークロードにあったRDBMSを選択する
2.1.1.1. OLTP
2.1.1.2. OLAP
2.2. プログラミング、ツール
2.2.1. N * M のやり方よりもN+Mのやりかた
2.2.2. スタイルガイドと静的解析ツールを使う
2.2.3. 不変データと関数型プログラミングを取り入れる