DNSにおいて、検索対象が存在しなかったことを示す不在応答のキャッシュ。

通常のキャッシュと同様に、名前解決の効率をあげるために、「検索対象が存在しなかった」という取得結果を一時的に保持しておく。

# 参考
- [JPRS用語辞典｜ネガティブキャッシュ](https://jprs.jp/glossary/index.php?ID=0177#:~:text=DNS%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E3%80%81%E6%A4%9C%E7%B4%A2%E5%AF%BE%E8%B1%A1%E3%81%8C,%E3%83%8D%E3%82%AC%E3%83%86%E3%82%A3%E3%83%96%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%80%8D%E3%81%A8%E5%91%BC%E3%81%B3%E3%81%BE%E3%81%99%E3%80%82)
- [ネガティブキャッシュ (negative cache)とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典](https://wa3.i-3-i.info/word12300.html)

ネガティブキャッシュ

# ラムダアークテクチャとは

ラムダアーキテクチャとは、膨大なデータ「ビッグデータ」を処理するアプローチ。従来のデータ基盤が得意とするバッチ処理の定期実行で得られる集計結果と、ストリーム処理によるリアルタイムの分析結果を組み合わせて分析できる。

## 背景

Hadoopの登場により、「ビッグデータ」という言葉が浸透した。ビッグデータは多量のデータを蓄積し、そのデータに対してバッチ処理を施すことで何らかの知見を得るというものが主だった。

バッチ的にビッグデータを扱っていたところ、やがてビッグデータに対してインタラクティブに分析・集計処理を実施することも可能になってきた。

やがてリアルタイム系技術が流行し、リアルタイム処理を強みの一つとして持つApache Sparkがブレークした。

バッチ処理は正確な結果を出力できるが、待ち時間が長いため、出力された頃には古いデータになっている。そうした課題感から、バッチ処理とリアルタイム処理のマージである「ラムダアーキテクチャ」というアプローチが提唱された。

# ラムダアーキテクチャを構成する3つのレイヤ

- バッチレイヤ
- サービングレイヤ
- スピードレイヤ(ストリームレイヤ)

![lambda_architecture](//images.ctfassets.net/8hndo4k4jdye/7nnnp9c46gyriwIavdZHut/ad7c1b4f5e027528f02cfd3069bd6320/hadoop-architecture.jpeg)
（画像出典: [ラムダアーキテクチャとは | Databricks](https://databricks.com/jp/glossary/lambda-architecture#:~:text=%E3%83%A9%E3%83%A0%E3%83%80%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%A8%E3%81%AF%E3%80%81%E8%86%A8%E5%A4%A7,%E3%81%9F%E3%82%81%E3%81%AB%E4%BD%BF%E7%94%A8%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82) ）

新しいデータはバッチレイヤとスピードレイヤに同時に供給される。

## バッチレイヤ

このレイヤでは、マスターデータセット(生データ)の管理や定期的なバッチ処理によるバッチビューの事前計算を行う。全てのデータを一度調べ、最終的にスピードレイヤ内のデータを修正する。

## サービングレイヤ

バッチレイヤ・スピードレイヤから出力されるデータが、サービングレイヤに転送される。この例やでは、バッチビュー(集計結果や分析可能な加工済みデータ)をクライアントに提供する。このビューはBIツールやSQLで参照可能なデータとなる。

## スピードレイヤ(ストリームレイヤ)

リアルタイム処理の結果を提供する層。直近数秒、数分、数十分のイベントの集計結果を提供する。

バッチレイヤのレイテンシで処理できずバッチビューでまだ配信されていないデータを処理する。リアルタイムビューを作成して、ユーザにデータの完全なビューを提供するために、最新のデータのみを扱う。

# ラムダアーキテクチャのメリット

サービスレイヤとスピードレイヤの双方に対して問い合わせをし、その結果をマージしてユーザに提供するようなクエリ機構を構築することで、バッチ処理の細やかな集計結果も、スピードレイヤの最新の集計結果も、分析に反映させることができる。

過去のデータとリアルタイムなデータを区別することなく、集計・分析することができる。例えば、マーケティング分野への活用が考えられる。ユーザのアクションを検知した際、そのユーザの過去と直近の双方の動向を理解した上で、そのユーザのアクションに対するリアクションをリアルタイムに決定できる。

# ラムダアーキテクチャの実現方法

難易度が高そうなのでそこまで調べていない...検討するべきときが来たらもう一度調べる。

# 参考
- [ラムダアーキテクチャとは | Databricks](https://databricks.com/jp/glossary/lambda-architecture#:~:text=%E3%83%A9%E3%83%A0%E3%83%80%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%A8%E3%81%AF%E3%80%81%E8%86%A8%E5%A4%A7,%E3%81%9F%E3%82%81%E3%81%AB%E4%BD%BF%E7%94%A8%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82)
- [Big Data + Fast Data = ラムダアーキテクチャー！ | NTTデータ先端技術株式会社](https://www.intellilink.co.jp/article/column/bigdata-kk03.html)
- [５分ちょいでわかった気になるラムダアーキテクチャ - Speaker Deck](https://speakerdeck.com/yubessy/5fen-tiyoidewakatutaqi-ninaruramudaakitekutiya)


ラムダアーキテクチャについて

# DevOpsとは
Development and Operationsの略。開発(Dev)担当者と運用(Ops)担当者が、開発手法やツールを使って緊密に協力・連携して開発を柔軟・迅速に進める仕組み。

DevOpsを導入することにより、市場投入までの時間の短縮、高い顧客満足度の創出、改良された製品の品質向上、ソフトウェアデリバリー・プロセスの自動化、信頼性の高いリリース、生産性や効率の改善、開発能力の育成、組織改革の強化などの相乗効果が生まれる。

## DevOpsが重視されるようになった背景
開発チームと運用チームの目指す方向性が相反してしまうことがあった。

- 開発者は、アプリの利便性を高めたい。
- 運用者は、安定的な運用をしたい。

# DevOpsのメリット
- スピードの向上
  - アジャイル開発などの非ウォーターフォールモデルの開発手法を採用することにより、機能ごとのリリースをスピーディにできる。
  - テスト期間を短縮し、早期にリリースできる。
- 生産性の向上
  - リリースサイクルが短く、ユーザーからのフィードバックを早期に得て改善点を修正できる。
  - 開発・運用の連携により効率的な情報のやり取りをする体制ができる。
  - ツールを使うことで、煩雑な作業の生産性を向上。Excel管理からの脱却.
- 信頼性の向上
  - 小さな規模で開発する手法であるため、バグや不具合を見つけやすく、見つけた場合も迅速に対応できる。
  - テスト、ビルド、デプロイなどのこれまで人間が行なっていた作業を自動化することで、ヒューマンエラーを防ぐことができる。

# DevOpsを実現する開発手法
- アジャイル
  - スクラム
  - エクストリームプログラミング
  - 機能駆動型開発
  - リーンソフトウェア開発
- 継続的インテグレーション(CI)
  - バージョン管理システムにソースコードをコミットした段階で自動的にソースコードのビルドとテストを実行することで、早期にバグを検出する。
- 継続的デリバリー(CD)
  - 全ての変更に対していつでも本番リリースが可能な状態を保証する。
  - ステージングまで自動化し、本番環境へのデプロイの決定は人間が行う。

# DevOpsを実現するツール
## バージョン管理システム
- Git
  - GitHub
  - GitLab

### ブランチ管理プラクティス
- Git Flow
- Git Hub Flow

## チケット管理システム
- Redmine
- Jira
- Backlog

## CIツール
- Jenkins
- Circle CI
- GitLab CI
- GitHub Actions

## CDツール
- Docker
- Vagrant
- Ansible
- Selenium

# 参考
- [DevOps とは? - DevOps と AWS | AWS](https://aws.amazon.com/jp/devops/what-is-devops/)
- [DevOps とは何ですか?DevOps の説明 | Microsoft Azur](https://azure.microsoft.com/ja-jp/overview/what-is-devops/)
- [DevOps | IT用語辞典 | 大塚商会](https://www.otsuka-shokai.co.jp/words/devops.html)

DevOpsについて

Kubernetes についてざっくりググったのでメモしておく。

# Kubernetes とは
コンテナ仮想化ソフトウェア（Dockerなど）の運用管理・自動化を行うために開発されたオープンソースソフトウェア。

コンテナは単体でアプリケーションを実行できるが、コンテナを管理したり他のサーバと連携させたりする機能は持っていない。

コンテナオーケストレーションツールのひとつ（コンテナオーケストレーションとは、複数あるコンテナを管理する技術のこと）。複数のコンテナを運用する場合、ネットワークやストレージなどの連携管理を行う必要がある。コンテナオーケストレーションツールはこれらの管理を行ってくれる。コンテナがダウンしたり、アプリケーションに高負荷がかかったりした場合もスムーズに運用できる。

## Kubernetes で登場する用語
- Pod: 複数のコンテナを管理する。Kubernetesで実行できるアプリケーションの最小単位。
- Node: 複数のPodをまとめる
- クラスター: Nodeが集まったもの

![Kubernetes Image](//images.ctfassets.net/8hndo4k4jdye/3w2mzXQat1qDijlKTe9u5E/013261b69bfe6b15b6c448cba46477ef/cdd11e74d1ab15b23a4ff6b87bbe2457.png)
（画像出典: [Kubernetesのコンポーネント | Kubernetes](https://kubernetes.io/ja/docs/concepts/overview/components/) ）

## Kubernetes のメリット
たくさんあるが3つピックアップする。

- サービスディスカバリー
- 自己回復機能
- ストレージ管理

以下それぞれの話。

### サービスディスカバリー
サーバにあるアプリケーションのポート番号やIPアドレスなどを知ることができる。また、どのようなアプリケーションが動いているのかを知ることもできる。

### 自己回復機能
コンテナがダウンしてしまったり誤って削除してしまったりした場合も自動で回復させることができる。（耐障害性が強い）

### ストレージの管理
ストレージが管理できる。データはコンテナに記録され、有効期限が定められた状態でPod内に保存される。

# Docker との違い
Dockerは、アプリケーションをコンテナの中で管理し、実行できるようにする実行環境およびツール群のこと。Kubernetesはクラスターという場所で実行されるのに対し、Dockerはシングルノードで実行される。クラスターとは、コンテナの配置や削除を行うときに指示を出す部分で、ノードとは、クラスタを構成している各サーバーを指す。

Docker はアプリケーションを各コンテナに分離するところまで。Kubernetes は、それぞれのコンテナを管理するところ（管理する手間を削減してくれるところ）を担当する。

# 各クラウドサービスのマネージド Kubernetes サービス

## GCPの場合
GKE（Google Kubernetes Engine）

https://cloud.google.com/kubernetes-engine

Kubernetes を使わないコンテナオーケストレーターサービスはない。

## Azureの場合
AKS（Azure Kubernetes Service）

https://azure.microsoft.com/ja-jp/services/kubernetes-service/#overview

Kubernetes を使わないコンテナオーケストレーターサービス

Service Fabric

https://docs.microsoft.com/ja-jp/azure/service-fabric/service-fabric-overview

## AWSの場合
EKS（Amazon Elastic Container Service for Kubernetes）

https://aws.amazon.com/jp/eks/

Kubernetes を使わないコンテナオーケストレーターサービス

ECS（Amazon Elastic Container Service）

https://aws.amazon.com/jp/ecs/

# 参考URL
https://kubernetes.io/ja/docs/concepts/overview/

https://udemy.benesse.co.jp/development/system/kubernetes.html

https://www.kagoya.jp/howto/cloud/container/kubernetes/

https://cloud-ace.jp/column/detail229/

https://www.redhat.com/ja/topics/containers/what-is-kubernetes


Kubernetes について

# eKYC とは

electronic Know Your Customers の略。電子（オンライン）での本人確認のこと。
ちなみに銀行や証券口座などの開設時に求められる本人確認のことをKYC と呼ばれており、それに電子（electronic）をつけただけ。

# 利用シーン

オンライン上での

- 銀行口座開設
- クレジットカード発行

など

# eKYC の法的根拠
金融庁「犯罪による収益の移転防止に関する法律」（犯罪収益移転防止法：犯収法）施行規則

## 2018年11月に法改正で追加された本人確定事項

1. 本人確認書類の画像+本人の容貌の画像送信
1. ICチップ情報+顧客の容貌の画像送信
1. 銀行等への照会
1. 顧客名義口座への少額振込

確認方法の追加についての概要資料は<a href="https://www.fsa.go.jp/news/30/sonota/20181130/01.pdf" target="_blank">こちら</a>

# 導入事例
- LINE Pay
- メルペイ

# 参考
<a href="https://www.ecbeing.net/contents/detail/240" target="_blank">eKYCとは？オンライン本人確認の利用場面や仕組み、安全性を紹介｜アスピック</a>

eKYC について

# レンダリングの前に

## HTMLを得るまで

アドレスバーにURLを入力してからHTTPレスポンスを得るまでには、ざっと下記のような流れを踏む。

1. DNSによりホスト名を解決し、IPアドレスを取得
1. HTTPによるリソースの取得
    1. TCP/IP接続の確立
    1. TLS接続の確立（HTTPSの場合）
    1. HTTPリクエストの送信、レスポンスを受け取る

レスポンスとしてHTMLを受け取ったところからの流れを以下にまとめた。

## レンダリングエンジンとJavaScriptエンジン

ブラウザ内部のソフトウェアコンポーネントのうち、画面表示に大きく関わるコンポーネントがレンダリングエンジンとJavaScriptエンジン。

### レンダリングエンジン

HTMLの描画エンジン。Webページのレンダリングのみを担当。HTMLや画像ファイルやCSS, Javascriptなどのリソースを読み取り、それを画面上の実際のピクセルとして描画する。
ブラウザの他にも、メールクライアントのHTMLメール表示や、アプリのWebViewなどに組み込まれている。

### JavaScriptエンジン

JavaScript実行環境を提供するコンポーネント。DOMツリーやCSSOMツリーなどの内部オブジェクトやAPIに対して、JavaScriptからアクセスできるようにするバインディングが提供される。

| ブラウザ     | レンダリングエンジン     | JavaScriptエンジン     |
| --- | --- | --- |
| Google Chrome       | Blink       | V8       |
| Internet Explore       | Trident       | Chakra       |
| Microsoft Edge       | EdgeHTML       | Chakra       |
| Mozilla Firefox       | Gecko       | SpiderMonkey       |
| Safari       | Webkit       | Nitro       |

# レンダリングの大きな流れ
1. Loading: リソースの読み込み
    1. Download
    1. Parse
1. Scripting
1. Rendering
    1. Calcuralte Style
    1. Layout
1. Painting
    1. Paint
    1. Rasterize
    1. Composite Layers

# 1-1 Download
リソースのダウンロードを行う。まずはHTMLをダウンロードする。

# 1-2 Parse

ダウンロードしたHTMLをレンダリングエンジンが解析(Parse)し、ブラウザの内部表現であるDOMツリーに変換する。この変換過程で、ツリー内に含まれる画像やCSS, JavaScriptなどのドキュメントに紐づくリソースの取得、ダウンロードを行う。（`<link>`, `<img>`, `<script>`で宣言されるリソース）

CSSもまたダウンロードされたのちレンダリングエンジンにより解析され、CSSOMツリーに変換する。

## HTMLの解析

DOMとは、HTMLの文書を表現するオブジェクトのこと。、HTML文書をツリー状のデータ構造として扱い、それをプログラムから参照したり操作したりするためのデータ構造やインタフェース ( API ) を定義したもの。DOMツリーは、レンダリングエンジンが利用する木構造を持つ内部表現。HTMLがDOMツリーに変換されるまでの工程は以下のとおり。

1. 字句解析: トークンのリスト化
1. 構文解析: 構文木の構築
1. DOMツリー構築（構文木内のJavaScriptを実行しつつ）

### 字句解析
ただの文字列であるHTMLを、意味的に1つの塊となった文字列の集合（トークンのリスト）に変換する。

### 構文解析
トークンのリストに分解されたものを使用して、構文木を構築する。構文木は木構造のデータ。

### DOMツリーの構築
構文木に含まれるJavaScriptを同期的に実行しつつ、DOMツリーを構築する。

たとえば、`document.write('SomeText');`というJavaScriptがあった場合は、その実行を待って書き出された文字列を同期的にトークンの列に追加する。

```html
<div>
  <h1>Title</h1>
  <p>Paragraph</p>
</div>
```

（DOMツリーの図）

## CSSの解析
CSSを解析して、CSSOM（CSS Object Model）と呼ばれるオブジェクトツリーを構築する。

```css
h1 {
  font-size: 21px;
}

#title {
  color: red;
  background-color: white;
  width: 200px;
}

```

(CSSOMツリーの図）

# 2. Scripting

ダウンロードされたJavaScriptを、レンダリングエンジンはJavaScriptエンジンに引き渡して実行させる。実行の過程は以下のとおり。

1. 字句解析: トークン列に変換
1. 構文解析: 抽象構文木に変換
1. コンパイル: 実行可能コードに変換
1. 実行

## 字句解析と構文解析

JavaScriptコード
```javascript
console.log('Hello, world!');
```

トークン列（ラベル付された文字列のリスト）

抽象構文木（JavaScriptの文法に沿った形で表現される木構造のデータ）

## コンパイル

抽象構文木を実行可能な形式に変換する。ここでの実行可能な形式は、JavaScriptエンジンにより異なる。

- 処理系内部の仮想マシン用のコードに変換
  - 返還後のコードを実行するための仮想マシンを用意し、そのマシンが実行できるコードを生成。
- JITコンパイルによる機械語への変換
  - その処理系が動作しているマシンのCPUが直接解釈できる機械語に変換。
  - 実行時にその場でコンパイルすることに由来（Just In Time)
  - V8もこれ
- その両方（トレーシングJIT）

# 3-1. Calculate Style

DOMツリーの全てのDOM要素に対し、どのようなCSSプロパティを当てるか計算する。
CSSOMのすべてを参照し、CSSOM:DOMの総当たりでセレクタマッチングする。
このとき詳細度も算出する。

## セレクタマッチング
セレクタマッチングは、セレクタの右から行う。

```css
body > .container > .button {
}

```
↑の場合、下記の順番で検証する。
1. .button はあるか
1. その親に .container はあるか
1. さらにその親の要素名は body  dearuka

# 3-2. Layout

DOMツリーのすべてのノードの視覚的レイアウト情報の計算を行う。（描画はまだしない）
視覚的レイアウト情報に含まれるのは、
- width, height
- margin
- padding
- position
- z軸の位置

# 4-1. Paint

内部の低レベルな2Dグラフィックエンジン向けの命令列を生成する。(ex: Skia、CoreGraphics)

# 4-2. Rasterize

Paint で生成された命令を用いて、ピクセル（ビットマップ）を描画する。このとき、レイヤーという単位で1枚ずつ描画する。
レイヤーが生成される条件は、下記のとおり。
- `position: absolute`なスタイルが適用されている
- `position: fixed`なスタイルが適用されている
- `transform: translate3d()`などのGPUで描画・合成されるプロパティを持っている
- `opacity`が指定されており、かつ投下して背景のコンテンツを表示する必要がある

## なぜレイヤーを生成するのか

再レンダリングのときに再利用できる場合があり、素早く再レンダリングできるため。例えば、スクロールするときは、スクロール分だけコンテンツの表示される位置ずらせばよく、コンテンツの描画そのものは変更する必要がないため、以前描画したレイヤーが再利用される。

# 4-3. Composit Layers

レイヤを合成して最終的なレンダリング結果を生成する。基本的にはCPUによって合成される。
下記の場合はGPUによって合成される。
- transformCSSで3D変形関数を指定している。
  - matrix3D, scale3D, rotateZ, translateZ など
- 特定のCSSFilterを使用している

# 再レンダリング

描画が終わってからも、JavaScriptの実行やドキュメント内のイベントによってレンダリングは繰り返される。
DOM操作を行えば、3-1 Calculate Style から行われる場合もあれば、4-2 Rasterize からで十分な場合もある。
また、Ajaxで外部リソースを取得した場合など、1-1 Download から再実行される場合もある。


ブラウザレンダリングの仕組み

# DNSレコードとは

DNSのゾーンファイル内に格納される情報(リソースレコード)。IPアドレスとドメイン名の対応などを定義する。レコードは格納する情報によって種類が分かれている。

# DNSレコードの種類

## Aレコード
- ホスト名とIPアドレス(IPv4)の関連付けを定義する。
- Address の A

## AAAAレコード
- ホスト名とIPアドレス(IPv6)の関連付けを定義する。

## CNAMEレコード
- ドメイン名の別名を定義する。
- 特定のホスト名を別のドメインに転送するときなどに使用する。
- エイリアスとも呼ばれる。

## NSレコード
- ドメインのネームサーバーのサーバー名を定義。

## TXTレコード
- ホスト名に関連づけるテキスト情報を定義。
- 送信ドメイン認証の認証情報(SPFレコード)などを記述。

## MXレコード
- ドメイン宛のメールの配送先(メールサーバー)のホスト名を定義。

# DNSレコードの設定項目

## TTL
- Time To Live
- リソースレコードをキャッシュに保持してもいい時間。
- 数値が小さいほどレコードのキャッシュの保持時間が短くなる。

# その他

## SPFとは
Sender Policy Framework。電子メールの送信元ドメインが詐称されていないか検査するための仕組み。

# 参考
- <https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/ResourceRecordTypes.html>
- <https://sendgrid.kke.co.jp/blog/?p=3509>


DNSレコードについてのまとめ

# DNSとは

Domain Name System。ドメイン名とIPアドレスの対応関係を管理するシステム。インターネットの住所録のようなもの。

- ドメイン名からIPアドレスを検索
- メールアドレスから送信先メールサーバを特定

# DNSの仕組み

## ドメインの構造

hoge社が保有する`hoge.co.jp`というドメインがあるとする。

- `jp`: TLD（Top Level Domain）またはccTLD（Country Code TLD）
    - TLDには他に、uk(ccTLD), edu, com(gTLD: Generic TLD)などがある。
- `co`: 属性を表す汎用ドメイン。
    - 他にtokyoなどの地域名を表すものなどがある。
- `hoge`: hoge社固有のドメイン名。

## ネームサーバ

ドメイン名を管理しているホストやソフトウェアのこと。ネームサーバが設置された階層(ゾーン)のドメインを管理。

## DNSの階層構造

DNSはツリー構造になっており、頂点にルートゾーンのドメインを管理するルートネームサーバがある。

下記のようなツリー構造

ルートネームサーバ → jpのDNSサーバ → hoge社のDNSサーバ
- ルートネームサーバ
  - jp階層のネームサーバのIPアドレスが登録されている。
- jpのDNSサーバ
  - jpのDNSサーバは日本国内のドメイン管理サーバ。
  - coの階層も管理している。
  - hoge社のネームサーバのIPアドレスが登録されている。

## リゾルバ

DNSに問合せを行うホストやソフトウェアのこと。PCなど。最低1つ以上のネームサーバのIPアドレスが登録されている(通常はその組織内のネームサーバのIPアドレス)

## DNSによる問合せ

`hoge.co.jp`から`xxx.co.jp`に問い合わせるとする。

1. リゾルバから、最も近いDNSサーバ（hogeのDNSサーバ）に`xxx.co.jp`のIPアドレスを問い合わせる。
2. hogeのDNSサーバはそのIPアドレスを知らないので、ルートネームサーバに問い合わせる。
3. ルートネームサーバはjpのDNSサーバのIPアドレスを知っているのでそれを返す。
4. jpのDNSサーバに問い合わせる。
5. jpはcoのDNSサーバのIPアドレスを知っているのでそれを返す。
6. coのDNSサーバに問い合わせる。
7. coはxxxのDNSサーバのIPアドレスを知っているのでのでそれをリゾルバに返す。(`xxx.co.jp`のIPアドレスが判明)
8. `xxx.co.jp`に問い合わせて通信が開始される。

- ドメインのツリー構造を上からたどって目的の情報があるネームサーバを見つける。
- 新たに知った情報を、リゾルバやネームサーバはしばらくの間キャッシュする。

## 権威DNSサーバ

ドメイン名とIPアドレスの変換情報を保持しているDNSのことで、変換情報を保持していないDNS（キャシュDNS）と区別するときに使う。

# 参考
ルートネームサーバの情報
- <https://www.internic.net/zones/named.root>
- <https://www.nic.ad.jp/ja/newsletter/No45/0800.html>


DNSについて調べたメモ

# SSG
Static Site Generation: 静的サイト生成。ビルド時にHTMLを生成し、リクエストがあると単にそのHTMLを返す。静的ページなのでCDNにキャッシュさせることも可能。

動的コンテンツがないサイトの場合はこれを選択。

Next.js の `getStaticProps` 内部で外部データの Fetch 処理を記述していると、ビルド時にサーバー側で Fetch を行い、そのデータを使用したHTMLを生成する。

# SSR
Server Side Rendering。リクエストごとにサーバー側でHTMLを作成して返す。

頻繁に変更される動的コンテンツがある場合に向く。

Next.js の `getServerSideProps` 内部で外部データの Fetch 処理を記述していると、リクエスト時にサーバー側で Fetch を行い、そのデータを使用したHTMLが返される。

# ISR
Incremental Static Regeneration: 漸進的な静的サイト生成。SSGのようにビルド時に静的HTMLを生成しておき、`stale-while-revalidate`というキャッシュコントロールの考え方に基づき、指定期間経過後にリクエストがあった場合はサーバー側でHTMLを再生成して返す。

HeadlessCMSを用いたブログなど、動的コンテンツを持ちつつも強整合性が求められなさそうな場面に適する。

Next.js の `getStaticProps` 内部で `revalidate: <秒>` のオプションを指定することで使用可能。

## stale-while-revalidate
HTTPレスポンスヘッダ`Cache-Control`に設定できるパラメータ。
```http
Cache-Control: max-age=3600, stale-while-revalidate=360
```
リクエストに対するキャッシュ済レスポンスが`max-age`で指定した期間より古い場合、その内容が"stale"(古いもの)であると判断される。通常であればこの時点でキャッシュを使用せずネットワークから直接レスポンスを得ようとする。

`stale-while-revalidate`を設定していれば、キャッシュされたレスポンスの経過時間が設定した時間内であれば、staleレスポンスの返送とリクエストのrevalidate(再評価)が並行して行われる。再評価リクエストに対するレスポンスが新たにキャッシュされ、次回以降のリクエスト時に使用できる。

キャッシュされたレスポンスの経過時間が設定した時間を超えていれば、ネットワークから直接レスポンスを取得し、それをキャッシュする。

# CSR
Client Side Rendering。クライアント側でDOMをレンダリングする。Reactの`useEffect`で Fetch してDOMに流し込むSPAなど。SEOやOGP対応などに不向き。

動的コンテンツがあり、強整合性が求められ、SEOやOGP対応など Pre-Render が不要なときに使用。ログインが必要なページは大体SEO,OGP対応が不要なので、これでOK。

Next.js(Vercel)では、`useSWR`というデータ Fetch 用 React Hook ライブラリを使用することが推奨されている。

# 参考
- <https://nextjs.org/docs/basic-features/data-fetching>
- <https://web.dev/stale-while-revalidate/>
- <https://nextjs.org/docs/basic-features/data-fetching#swr>
- <https://zenn.dev/a_da_chi/articles/105dac5573b2f5#csr%E3%81%A8%E3%81%AF>
- <https://qiita.com/thesugar/items/47ec3d243d00ddd0b4ed>

SSR と SSG と ISR と CSR

下記の3つの指標で構成される、Googleの新しい検索ランキング要因。

- LCP: 最大コンテンツの読み込み時間
- FID: インタラクティブ性
- CLS: 視覚的な安定性

# LCP
Largers Contentful Paing: 最大コンテンツの読み込み時間。ページ内のメインコンテンツがダウンロードされてから操作できるようになるまでの時間。LCPが良好だとする基準は2,500ms。
ViewPort内の画像もしくはブロック要素の内、最大となるコンテンツが対象となる。測定される一般的な要素は、画像・ビデオ・段落タグのようなブロックが対象となり、divも対象となる可能性がある。

# FID
First Input Delay: インタラクティブ性。URLやボタンのクリックやタップと言ったアクションを、ページ内で最初にユーザーが試みてから、ブラウザが応答できるようになるまでの時間。目標時間は100ms。300msを超えると不良。

# CLS
Cumulative Layout Shift: 視覚的な安全性。ページのレイアウトが安定しているかを測定。縦横サイズ指定のない画像や、Webフォントを表示させる際のちらつきや広告によって、スコアが悪くなる。

# 参考
- [https://developers-jp.googleblog.com/2020/05/web-vitals.html](https://developers-jp.googleblog.com/2020/05/web-vitals.html)
- [https://web.dev/vitals/](https://web.dev/vitals/)

CWV : Core Web Vitals について

認可周りを表現するための設計。「ユーザー」と「許可」の二つの概念をテーブル設計に落とし込む。

# DAC
Discretionaly Access Controll: 任意アクセス制御。「ユーザー」と「許可」をそれぞれのテーブル`users`, `permissions`とし、誰がどの許可を持っているかを関連テーブルで管理する。

![dac](//images.ctfassets.net/8hndo4k4jdye/4zsSzDVAENxCjFCwTLOK6t/29d9c1f5178be90b3afe5c9b4774b150/dac.png)

- Pros
  - 許可の種類が増えてもテーブル構成が変わらない
- Cons
  - 複数の同じ許可をもつユーザーを作成するとき、毎回設定する必要がある。
    - 例）10種類の許可を持つユーザーを2人作成するとき、`user_permissions`にレコードが20行必要。

# RBAC
Roll Based Access Controll: ロールベースアクセス制御。「ユーザー」と「許可」意外に、「役割」という概念も加える（`role`テーブル)。許可：役割の関連テーブルと、ユーザー:役割の関連テーブルを作る。

![rbac](//images.ctfassets.net/8hndo4k4jdye/6d0wn7zUspDALxdiy2KMpl/df68e84b639964f92dda29c470e906f1/rbac.png)

- Pros
  - 同じ許可の組み合わせを持つユーザーを作成するとき、`user_roles`に1行追加するだけでいい。
  - ある役割の許可の組み合わせを変更したいとき、`role_permissions`を変更するだけで、その役割のすべてのユーザーに変更を反映することができる。
- Cons
  - 役割に対して一意に許可を付与するため、動的に許可を付与することができない。
  - 複雑な許可の組み合わせを作る要件がでてくると、その都度新しい役割が増えていく。


DAC と RBAC 認可周りのテーブル設計

GraphQL で構築した API にGETリクエストを投げたとき、リソースが存在しない場合にnullが返却され、ステータスは 404 ではなく 200 で返ってきてしまう。

200 を返したまま表示だけは NotFound ページへ遷移させるやり方でもいいのだが、Next.js の`getStaticProps`でリクエストしているときは`{ notFound: true }`を return することで、404 を返して自動で 404 ページに遷移させることができる。
```TypeScript
export const getStaticProps: GetStaticProps<Props> = async ({ params }) => {
  // Fetchする処理
  const result = { data: null };

  if (!result.data) {
    return {
      notFound: true,
    }
  }

  return {
    props: {
      data,
    },
  }
}
```

# 参考
[https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation)

Next.jsのgetStaticPropsで手動で404を返したい

`pages/404.js`作るだけ。
```javascript
// pages/404.js
export default function Custom404() {
  return <h1>404 - Page Not Found</h1>
}
```

500エラーも`pages/500.js`を作ればカスタムできる。
```javascript
// pages/500.js
export default function Custom500() {
  return <h1>500 - Server-side error occurred</h1>
}
```

サーバーに依存したエラーを扱いたい場合など、デフォルトの Error コンポーネントをオーバーライドする場合は、`pages/_error.js`を作る。
```javascript
function Error({ statusCode }) {
  return (
    <p>
      {statusCode
        ? `An error ${statusCode} occurred on server`
        : 'An error occurred on client'}
    </p>
  )
}

Error.getInitialProps = ({ res, err }) => {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404
  return { statusCode }
}

export default Error
```

# 参考
[https://nextjs.org/docs/advanced-features/custom-error-page](https://nextjs.org/docs/advanced-features/custom-error-page)

Next.jsで404ページをカスタマイズする方法

Vercel に GitHub で管理するプロジェクトのデプロイを試した際のメモ。

# Vercel & GitHub デフォルトの挙動

- push ごとにデプロイが走る
  - すべてのブランチが対象
  - P-R を含む
  - push したときに build 中だったら、キャンセルされて新しいデプロイがはじまる。
- カスタムドメインを設定している場合、main ブランチへ merge されると自動で更新される。
  - revert も可能
- P-R ごとにユニークな Preview URL が生成され、P-R のコメント欄に貼られる。

# Vercel のデプロイタイプ

## Preview Deployment

- ブランチへの push や vercel コマンドの実行のたびにデプロイされる環境。
  - preview URL が更新され、最新のデプロイが反映される。
  - preview URL は、 push や P-R のたびに生成され、ユーザー名やチーム名が含まれる。
- `X-Robots-Tag` HTTP header が `noindex`に設定されているため、検索エンジンにインデックスされることはない。
  - preview URL にカスタムURLが割り当てられている場合は、`noindex`が設定されない。

## Production Deployment
- main ブランチへの merge や、`vercel --prod`コマンドによるデプロイで生成される本番環境。
  - 本番ドメインに最新のデプロイが反映される。

# その他
- `{DeployedURL}/_src` でデプロイインスペクタを開くことができる。
- `{DeployedURL}/_logs` でデプロイビルドプロセスとサーバーレス呼び出しからのログを開くことができる。
  - これらはログインしないと閲覧できないため、セキュリティ上の懸念はない。
- Build のたびに、前回の Build で生成されたキャッシュが復元される。
  - 選択されたフレームワークに応じて、`node_modules`や`package-lock.json`を自動的にキャッシュする。
  - Build ステップの最後に、キャッシュを更新する。
  - Redeploy ボタンまたは `vercel --force` コマンドによるデプロイでは、Build キャッシュは使用されない。
  - キャッシュは最大500MB, 1ヶ月保存される。

# 参考

## Vercel 公式
- [https://vercel.com/docs/git/vercel-for-github](https://vercel.com/docs/git/vercel-for-github)
- [https://vercel.com/docs/platform/deployments#deployment-types](https://vercel.com/docs/platform/deployments#deployment-types)
- [https://vercel.com/docs/build-step#caching](https://vercel.com/docs/build-step#caching)

## X-Robots-Tag について
- [https://developers.google.com/search/docs/advanced/robots/robots_meta_tag#xrobotstag](https://developers.google.com/search/docs/advanced/robots/robots_meta_tag#xrobotstag)

zerosantのメモ帳