仕事でGKEを使用する必要があるので、 
自分用にまとめていきたいと思います。

便利な機能
- リリースチャネル
- Nodeの自動アップデート、自動修復機能
- Nodeの自動プロビジョニング機能(ノードのインスタンスタイプを自動で決定してくれる)など

 

# Nodeについて
- GCE(Goole Compute Engine)が利用されている
- GCEはプリエンプティブルインスタンス(起動時間に24時間制限ありの低コストインスタンス)
- プリエンプティブルインスタンスの場合、ちゃんと設定しないとNodeが停止することがある
- プリエンプティブルインスタンスの場合、24時間後に全Nodeが停止する可能性があるため、Preempible-killer(ランダムに徐々にNodeを入れ替える)の利用を検討する

 

# GKE
- Cloud Loggingがデフォルトで連携
- 高性能なHttp loadbalancer(Ingress)
- GPUの利用もできる

 

# NodePoolについて
クラスタ内のNodeにラベル付けし、グルーピングするような機能
ex:
- vCPU数が多い => NodePoolA
- メモリ容量が多い => NodePoolB
こんな感じでグループ分けできる

## GCP SDK
```bash
# GCP SDK install
curl https://sdk.cloud.google.com | bash

# gcloudコマンドを使用できるようにシェルを再起動
exec -l $SHELL

# gcloud CLI認証
gcloud init

# GKEで利用可能なk8sのバージョンを確認
gcloud container get-server-config --zone asia-northeast1-a
```

## クラスターを作成
```bash
gcloud container clusters create k8s \
--cluster-version 1.29.7-gke.1104000 \
--zone asia-northeast1-a \
--num-nodes 3

# gke-gcloud-auth-pluginが見つからないとエラーになるとき
gcloud components update
gcloud components install gke-gcloud-auth-plugin

# 上記で作成したk8sクラスターにアクセス
gcloud container clusters get-credentials k8s --zone asia-northeast1-a
```
Fetching cluster endpoint and auth data.
kubeconfig entry generated for k8s.
👆のように`k8s`の名前になっていればOK

 

## GCPユーザー
```bash
# 現在のユーザー確認
gcloud config get-value core/account
# 変更がなかったら環境変数に追加
GCP_USER=`gcloud config get-value core/account`

# 上記のユーザーにクラスタ管理者権限を付与
kubectl create --save-config clusterrolebinding iam-cluster-admin-binding \
--clusterrole=cluster-admin \
--user=${GCP_USER}
```
clusterrolebinding.rbac.authorization.k8s.io/iam-cluster-admin-binding created
👆このようになればOK

 

## クラスターの削除
```bash
gcloud container clusters delete k8s --zone asia-northeast1-a
```
 

GKEの詳細情報
https://cloud.google.com/kubernetes-engine/?hl=ja

## その他のプライグラウンド
- 最大５台のインスタンスの起動OK
- 連続利用時間が4時間まで

https://labs.play-with-k8s.com/

GKEでクラスターの作成から削除まで

## はじめに

個人開発をしていてネックなのが、 
バックエンドとデータベースのサーバー代が高額になってしまうことだと思います。 
そこで、サーバーレスな`Lambda`を使ってきましたが、 
今までよく使用していた`Serverless Framework`のプラグインである、 
`lambda-layers`が廃止されてしまったりで、 
色々検討した結果、`GCP`でうまくできないかと思いました。

 

https://www.npmjs.com/package/serverless-layers

 

`GCP`には`Lambda`と同じような`Cloud Functions`がどうやらあるらしいとわかったので、 
どれくらいのパフォーマンスが出せるのか検証していきたいと思い、 
この記事を書くことにしました。

 

今回は、単純にカスタムな処理は入れず下記の公式記載の関数作成方法で実装し、 
まっさらな状態で各言語別にどれくらい差が出るのかを出し、今後の技術選定の参考にしたいと思います。

 

https://cloud.google.com/functions/docs/create-deploy-http-python?hl=ja

 

| 内容 | 対象 |
| ------ | ---------------------------- |
| 言語 | Node.js, Nest.js, GO, Python |
| テスト | k6 |

## テスト結果

k6で1人が10回アクセス
| 回数 | Nest.js | Go | Node.js | python |
| ---- | -------- | -------- | -------- | -------- |
| 1 | 20.671ms | 16.931ms | 15.825ms | 18.703ms |
| 2 | 23.115ms | 19.217ms | 16.876ms | 17.686ms |
| 3 | 22.308ms | 17.899ms | 16.082ms | 22.985ms |
| 4 | 22.277ms | 18.485ms | 17.733ms | 12.83ms |
| 5 | 18.387ms | 17.627ms | 20.764ms | 15.326ms |
| 6 | 20.014ms | 17.255ms | 15.563ms | 12.576ms |
| 7 | 17.388ms | 18.98ms | 18.137ms | 12.879ms |
| 8 | 24.626ms | 13.526ms | 28.926ms | 12.833ms |
| 9 | 20.029ms | 15.712ms | 30.627ms | 12.554ms |
| 10 | 17.54ms | 14.183ms | 30.627ms | 19.061ms |

## k6メトリクス

- Nest.js

```bash
http_req_duration..............: avg=20.63ms min=17.38ms med=20.35ms max=24.62ms p(90)=23.26ms p(95)=23.94ms
```

- Golang

```bash
http_req_duration..............: avg=16.98ms min=13.52ms med=17.44ms max=19.21ms p(90)=19ms p(95)=19.11ms
```

- Node.js

```bash
http_req_duration..............: avg=19.85ms min=15.56ms med=17.88ms max=30.62ms p(90)=29.09ms p(95)=29.86ms
```

- Python

```bash
http_req_duration..............: avg=15.74ms min=12.55ms med=14.1ms max=22.98ms p(90)=19.45ms p(95)=21.21ms
```

 

`Nest.js`は`nest new APP_NAME`で生成された状態のままで 
`Cloud Functions`にデプロイした状態です。 
なので、ちょっとオーバーヘッド気味ですが、 
その他のフレームワークを使用しない感じだと、 
そこまで大差がないことがわかりました。

イメージ的に`GO`が圧倒的に速いのかと思っていたので、
少しびっくりです😶

PCの環境にもよると思いますので、
ご参考までにご覧いただけると幸いです。

【GCP】 Cloud Functionsで速度比較をしてみた

GCPのCLIが必要になったので、 
簡単なことですが次回やる時にすぐできるよう備忘録で残しております。

 

## tar.gzインストール

自分の使用PCは高性能ではないので、 

`macOS 64 ビット(x86_64)`を画面上からインストールします。

リンクは下記の公式から。

https://cloud.google.com/sdk/docs/install?hl=ja

 

## 解凍からインストール

指定した場所に保存して、保存ディレクトリまで移動し下記コマンドを実行

 

```bash
./google-cloud-sdk/install.sh
```

 

色々質問が来るが、
最初の`Do you want to help improve the Google Cloud CLI(訳: Google Cloud CLI の改善に協力しますか?)`は協力できる自信がないので、`N`を選択。 
その他はメッセージに従い`Y`を選択してインストールが完了。

 

途中、 
`Enter a path to an rc file to update, or leave blank to use(訳: 更新するrcファイルへのパスを入力するか、空白のままにして)` 
で、.zshrcに自動的に自動的に書き込まれたので下記コマンドで再読み込み。

```bash
source ~/.zshrc
```

 

## バージョン確認

```bash
gcloud -v
```

【GCP】 gloud cliをインストールする

とある企業さんとのカジュアル面談時に、 
面談相手のエンジニアへキャッチアップはどのようにしているかを聞いてみたら、 
下記のシステム設計などをみたりしていると教えてもらったので、 
その中から興味があった、負荷分散の項目を追ってみようと思う。 

 

## 一般的な負荷分散アルゴリズム(ロードバランサーを使用した場合)
1. ラウンドロビン

![Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/roundrobin.webp "Round Robin")

ユーザーからのリクエストに対して、順番にサーバーへ送信される。 
簡単な設計だが、サーバー側の負荷を考慮しないので、サーバーAが死んだ場合もリクエストが送られてしまう。

 

2. スティッキーラウンドロビン

![Sticky Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/stickyRoundRobin.webp "Sticky Round Robin")

ユーザーからのリクエストはずっと同じサーバーに送信するようにする。 
セッションパーシステムを実現するためのアルゴリズム。 
特にユーザーのセッション状態を維持してサービスを展開したいもの(ECサイトなどなど)に有効。 
しかし、これも同じサーバーに接続し続けるのでサーバーが死んだらエラーになってしまい、負荷が均等に分散されない。 
※ セッションパーシステム 
特定のユーザーから来る一連のリクエストを同じサーバーに振り分けること。 
 
下記でセッションを固定している 
・IPアドレスベースでセッションを固定 
・ユーザーにセッションIDを割り当てて固定 
・Cookieを使用してセッション情報を保持して固定

 

3. 加重ラウンドロビン

![Weighted Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/WeightedRoundRobin.webp "Weighted Round Robin")

各サービスに対して重みを設定する。 
図だとServiceAに80%,その他に10%ずつ重みを設定している。 
そうすると80%までのリクエストはServiceAに、81%〜90%はServiceB、90%〜100%はServiceCに割り振られる。 
サーバーの能力に応じて重みを設定することが大事。

 

4. ハッシュ

![IP URL Hash](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/ipUrlHash.webp "IP URL Hash")

受信トラフィックの送信元と送信先のIPアドレス、URLを組み合わせて、 
数学的関数を使用しハッシュに変換。そのハッシュの値で指定したサーバーに割り振られる。
図だと、req1, req2のipアドレスやURLが0になると、ServiceAのインスタンスにルーティングされる。

 

5. 最小接続数

![Least Connections](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/leastConnections.webp "Least Connections")

同時接続数が最も少ないサービスに送信される。
サーバー間の負荷を均等に分散できるため動的な環境に適している。

 


6. 最短応答時間

![Least Time](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/leastTime.webp "Least Time")

最もレスポンス時間が短いサーバーに送信される。 
リアルタイムにサーバーのパフォーマンスを監視し、動的に負荷を分散している。

 

※ロードバランサーは、複数サーバー間でのトラフィックを効率的に分散する

## まとめ
なんとなくで負荷分散している部分もあったので、
こういったアルゴリズムを取り入いれ品質を高めていこうと思う今日この頃。

【システム設計1】 負荷分散アルゴリズムについて考えてみる

普段AWSメインで触っていますが、 
他のGCPやAzureの名前を聞いても何の役割か分からないので、 
多分よく使用することが多いであろうリソースを、 
AWSを基準に一覧表で作成しました。

https://cloud.google.com/docs/get-started/aws-azure-gcp-service-comparison?hl=ja

上記をもとにまとめています。 
誤っていましたら申し訳ございません。

 

|分類|AWS|GCP|Azure|役割|
|----|----|----|----|----|
|コンテナ|EKS (Elastic Kubernetes Service)|GKE (Google Kubernetes Engine)|AKS (Azure Kubernetes Service)| Kubernetesを実行|
||Fargate|Cloud Run|Azure Container Apps|サーバーレスにコンテナごとデプロイができる|
|コンピューティング|EC2|Compute Engine|Azure Virtual Machines|仮想マシン|
||Lambda|Google Cloud Functions|Azure Functions|サーバーレスにAPIを構築できる|
||AWS Auto Scaling|Compute Engine オートスケーラー|Azure Autoscale|オートスケールできる|
|アプリケーション統合|Step Function|Workflows|Azure Logic Apps||
||SQS|Cloud Tasks|Azure Storage Queues|分散システム間でのメッセージの送受信|
||EventBridge|Cloud Scheduler|Azure Scheduler|cronジョブ|
|ビジネスアプリケーション|Chime|Google Meet|Teams|ビデオ通話、チャット|
|データベース|RDS|Cloud SQL|Azure Database for MySQL Azure Database for PostgreSQL|RDBMS|
||DynamoDB|Datastore|Azure Cosmos DB|NoSQL|
|デベロッパーツール|X-Ray|Cloud Trace|Azure Monitor Application Insights Distributed Tracing|パフォーマンス障害を検出|
|CI/CD|AWS CodeCommit、 AWS CodeBuild、 AWS CodeDeploy|Google Cloud Deploy|Azure DevOps|CI/CD|
|ウェブとモバイルのフロントエンド| AppSync|Firebase Realtime Database|Azure Cosmos DB| GraphQL API|
||ApiGateway|ApiGateway|Azure API Management|Apiの管理|
||Amplify|Firebase Hosting||デプロイ、ホスト、構築|
|ネットワーキングとコンテンツ配信|VPC|Virtual Private Cloud|Azure Virtual Network||
||CloudFront|Cloud CDN |Azure Front Door|CDN|
||Route53|Cloud DNS Cloud Domains|Azure DNS|DNS,ドメイン管理|
||ELB|Cloud Load Balancing|Azure ロードバランサ|ロードバランサー|
|セキュリティ|WAF|Google Cloud Armor|Azure Web Application Firewall||
||KMS|Cloud KMS|Azure Key Vault|暗号化キーの作成、管理|
|認証認可|Cognito|Firebase Auth|Azure App Service 認証||
|ストレージ|S3|Cloud Storage Cloud Storage for Firebase Cloud Storage Archive|Azure Blob Storage Azure Archive Storage||
|モニタリング|ClooudWatch|Cloud Monitoring|Azure Monitor||
|ログ|Amazon CloudWatch Logs|Cloud Logging|Azure Monitor ログ||

 

他に必要なものがあったら随時追加しようと思います。

主要なクラウドサービスプロバイダをまとめる

## プロジェクトのセットアップ

 

1. まず下記からアカウントを作成します。 
 https://sentry.io/signup/

 

2. プロジェクトのセットアップ 
 アカウント作成後、下記のような画面になるので 
 一度`Skip onboarding.`でダッシュボードを開きます。
 ![Welcome to Sentry](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/sentry/1.png 'Welcome to Sentry')

 

 下記のような画面に遷移するので、`Create project`をクリックします。

 ![Create Project](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/sentry/2.png 'Create Project')

 

 画面に表示された質問に対して答えていきます。

 ```
 1. Choose your platform
 Next.js

 2. Set your alert frequency
 Alert me on every new issue

 3. Name your project and assign it a team
 Project nameに任意のプロジェクト名を入力
 ```

 

3. Next.js SDK

下記の画面に遷移するので、Sentryウィザード(自動でSentryの設定ファイルなどを作ってくれる)を使用して構成します。

```shell
npx @sentry/wizard@latest -i nextjs
```

下記のように進めていきます。

```shell
Need to install the following packages:
@sentry/wizard@3.22.1
Ok to proceed? (y) y


Are you using Sentry SaaS or self-hosted Sentry?
│ ● Sentry SaaS (sentry.io)
│ ○ Self-hosted/on-premise/single-tenant

# Yesを選択後Sentryにログインします
Do you already have a Sentry account?
│ ● Yes / ○ No

# プロジェクト選択後、@sentry/nextjsがインストールされます
Select your Sentry project.
│ ● 設定したプロジェクト名

# Noを選択下記のファイルがルート直下に作成されnext.config.mjsにsentryの設定が入っていきます。
# sentry.server.config.ts
# entry.client.config.ts
# sentry.edge.config.ts
Do you want to route Sentry requests in the browser through your NextJS server to avoid ad blockers?
│ ○ Yes
│ ● No (Browser errors and events might be blocked by ad blockers before being sent to Sentry)
```

 

すでに、`_error.ts`がある場合`captureUnderscoreErrorException`を追加するように言われます。

```typescript:_error.ts
ErrorPage.getInitialProps = async (context: NextPageContext) => {
 const { res, err } = context;
 const statusCode = res ? res.statusCode : err ? err.statusCode : 404;

 if (err) {
 // このページに来た例外をキャプチャ
 await Sentry.captureUnderscoreErrorException(context);
 }

 return { statusCode };
};
```

質問の続き

```shell
Did you modify your src/pages/_error.tsx file as described above?
● Yes / ○ No, get me out of here

# 下記でサンプルを作成すると`pages/api/sentry-example-api.js`とpages/sentry-example-page.jsx`が作成されます。
◇ Do you want to create an example page ("/sentry-example-page") to test your Sentry setup?
│ Yes
```

 

## ダッシュボードからモニタリング

プロジェクトのセットアップが終わったので、 
サンプルの`/sentry-example-page.jsx`にアクセスし例外を発生させてみます。

 

下記の画面のように発生したエラーが表示され、 
詳細を見てみると下記の情報を確認することができます。

![Dashboard](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/sentry/3.png 'Dashboard')

 

例外が発生したユーザーのIPアドレスや使用ブラウザなど詳細に確認することができます。

 

## Vercelとの連携

当ブログはVercelにデプロイしているので連携します。 
やり方はSentryのドキュメントにあるのでこちらにそって連携します。

 

https://docs.sentry.io/product/integrations/deployment/vercel/

 

1. Sentryのマーケットプライスへ接続
 https://vercel.com/integrations/sentry

`Add Integration`をクリックし、 
VercelとSentryの対象のプロジェクトをそれぞれ選択します。

自動的にSentryで必要な下記の環境変数が設定されます。

```shell
SENTRY_AUTH_TOKEN
VERCEL_GIT_COMMIT_SHA
NEXT_PUBLIC_SENTRY_DSN
SENTRY_PROJECT
SENTRY_ORG
```

読み込む対象の環境は必要に応じて変更します。

2. Sentryファイルから環境変数で管理するところを修正

```javascript:next.config.mjs
export default withSentryConfig(
 {
 silent: true,
 org: process.env.SENTRY_ORG,
 project: process.env.SENTRY_PROJECT,
 },
 ...省略
)
```

 

`sentry.client.config.ts`
`sentry.edge.config.ts`
`sentry.client.config.ts`の`dsn`を環境変数に変更
プラス、`environment`を追加し、現在のステージがどこか分かりやすくする。

```typescript:〇〇.config.ts
// dnsを修正
Sentry.init({
 dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
 ...省略
})
```

 

ここまで設定が終わったら、再度デプロイ後、 
例外発生ページの`/sentry-example-page`から例外を発生させれば 
Sentryの画面上で確認できるようになる。

 

## 引用リンク

https://zenn.dev/keitakn/articles/add-sentry-to-nextjs-vercel

当ブログにSentryを導入した【Next.js page router】

## はじめに

このブログはNext.jsで作っています。
Next.js便利だなと思っている反面、他にいいものはないかなと調べていたら、、

 

https://www.epicweb.dev/why-i-wont-use-nextjs

 

こういう記事を目にすることがあり、 
ちょっとRemixを触ってみようという気になったので、 
すごい初歩のRemixクイックスタートの記事を書いてみました！

 

https://remix.run/docs/en/main/start/quickstart

 

## CLIを使用する場合

下記のように進むとRemixがテンプレートを作ってくれる。

```bash
npx create-remix@latest

# 質問
Where should we create your new project?
.

Initialize a new git repository? (recommended)
No

Install dependencies with npm? (recommended)
Yes

```

ちょっと、npmで構成している時間が1分くらいあったので遅いかなと感じました。

なので、今回は公式にもあるように一から進めてみようと思います。

 

## 一から作っていく場合

```bash
mkdir remix-app && cd remix-app
npm init -y

# remixをインストール
npm i @remix-run/node @remix-run/react @remix-run/serve isbot@4 react react-dom
# typescript使用時
npm i -D @types/node @types/react @types/react-dom typescript

# ビルドツールはviteを使用
npm i -D @remix-run/dev vite vite-tsconfig-paths
```

どうやら、RemixはViteを使用しておりプラグインが充実している。 
こちらも公式に沿ってViteの設定をする。 
他にもViteより10倍早いと言われている`Turbopack`もあるがRemixのプラグインにあるか調べきれてないので、 
とりあえず、Viteで進める。

```javascript:vite.config.ts
import { vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths"

export default defineConfig({
 plugins: [ remix(), tsconfigPaths()],
 server: {
 port: 3001,
 },
 build: {
 outDir: "build"
 }
});
```

このファイルでポートを任意の番号に変更できる。

 

## ルートを作成

```bash
mkdir app
touch app/root.tsx
```

```typescript:root.tsx
import { Links, Meta, Outlet, Scripts, ScrollRestoration } from "@remix-run/react"
import { ReactNode } from "react";
import "@/styles/global.scss"

export function Layout({children}: {children: ReactNode}) {
 return (
 <html lang="ja">
 <head>
 <meta charSet="utf-8"/>
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <Meta />
 <Links />
 </head>
 <body>
 {children}
 <ScrollRestoration />
 <Scripts />
 </body>
 </html>
 )
}

export default function App() {
 return <Outlet />;
}
```

これが大元を司っているファイル。 
`ScrollRestoration`は、ブラウザのスクロール位置を覚えておき、 
ブラウザバックで戻ってきたときに、同じ位置で表示してくれる。

 

# viteの設定ファイルを作成

```typescript:vite.config.js
import { vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths"

export default defineConfig({
 plugins: [ remix(), tsconfigPaths()],
 server: {
 port: 3001,
 },
 build: {
 outDir: "build"
 }
});
```

package.jsonに追記。

```shell
"dev": "remix vite:dev",
"build": "remix vite:build"
```

無事に`localhost:3001`で起動した！

このコマンドは、 
`Cloudflare Workers、Netlify、Vercel、Fastly、AWS、Deno、Azure、Fastify、Firebase`などどの環境でも動作するようにできている。

また独自のサーバーを組み込むことも可能。 
しかし、RemixはViteを推しているようなのでこのままViteを使ってみる。

 

## Tailwindを入れてみる

せっかくなので、TailwindCssを導入してみる。

```
npm i tailwindcss postcss autoprefixer sass
```

個人的にcssよりsassの方が好きなのでここで一緒に入れておく。

### 設定ファイルを生成

```
npx tailwindcss init -p
```

### tailwind.config.js

上記のコマンドで`tailwind.config.js`ファイルが作成されている。 
appディレクトリ以下に適用させるように設定。

```javascript:tailwind.config.js
/** @type {import('tailwindcss').Config} */
export default {
 content: [
 "./app/**/*.{js,ts,jsx,tsx}",
 ],
 theme: {
 extend: {},
 },
 plugins: [],
}
```

### グローバルscssファイルで読み込む

```css:global.scss
@tailwind base;
@tailwind components;
@tailwind utilities;
```

これで無事にTailwindのスタイルが適用された！

 

## まとめ

Next.jsを使用していると、結構ブラックボックスになる部分が個人的にはあると思っていたので、 
ゼロイチのような感じで構築できていけるのは書いてて楽しい気がする😇 
ちょっとハマりそうなので、今後ルーティングやサーバー側の処理の内容を書けたらなって思っている！

 

https://github.com/zaki-app/remix-app

【Typescript】Remixクイックスタート

普段はwebアプリ開発をしていますが、 
ブラウザ内部で実装したコード達がどのように動いているのかなんとなくでしかわかっていなかったので、 
ちょっと調べてみた系の記事です。

 

## ブラウザの全体的な構造

![ブラウザ全体構造](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/browser.webp 'ブラウザ全体構造')

この図の四角がブラウザのコンポーネントというらしいです。

 

## コンポーネントの役割

1. User Interface

- アドレスバーや、進む、戻る、リロードボタンやお気に入りなど、
 chromeを開いたときに目に見えるもの全部

2. Browser Engine

- UIとレンダリングエンジンの中間にいて、2つの間でのアクションをそれぞれにわかりやすく変換する役割
- UIから入力を受け取り、それを元にレンダリングエンジンへ命令を渡す

3. Rendering Engine

- 2からの命令に従ってブラウザ画面にちゃんと表示できるように働く場所
- 全てのコンポーネントで `ここが一番負荷がかかっていて大事な部分`
- HTMLがリクエストされた場合は、ここでHTML, CSSを解析してパパッと画面に出せるように頑張る
- #### `なので、このコンポーネントが解析しやすいコードにしないとパフォーマンスが落ちるということ`
- 代表的なレンダリングエンジン
 - Blink(Chrome, Edge, Operaなどで使用)
 - Webkit(Safariで使用)
 - Gecko(Firefoxで使用)

4. Networking

- リクエスト...ブラウザがHTTPやHTTPSリクエストを送信して、HTML, CSS, Javascript, 画像などを取得する
- レスポンス...受け取ったレスポンスをレンダリングエンジンや、ブラウザエンジンに渡したりする

5. Javascript Interpreter

- JSコードを解析して実行するために使用される
- 代表的なJSエンジン
 - V8(Chrome, Edge)
 - JavascriptCore(Safari)
 - SpiderMonkey(Firefox)

6. UI Backend

- UIで操作した(クリックなど)ことを裏側で行うために使用

7. Data Persistence

- Cookie, LocalStorage, SessionStorage, IndexedDB, WebSQL, FileSystemなどデータ永続性のために使用

 

## レンダリングエンジンについてもう少し詳しく

Webアプリ開発において、このコンポーネントからレンダリングエンジンについて考慮する必要がかなりある。

 

https://web.dev/articles/howbrowserswork?hl=ja

 

レンダリングエンジンは、各タブごとにそれぞれのプロセスで実行される。

## レンダリングエンジンの内部処理の流れ

![レンダリングエンジン](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/render.webp 'レンダリングエンジン')

1. HTMLを解析してDOMツリーを構築

- HTMLを受け取り、画面を構成するためDOMツリーを構築する

https://ja.javascript.info/dom-nodes

- CSSを適用
 1で構築したDOMツリーに対し、外部ファイルやスタイルタグのCSSを解析する。
 この解析結果は、CSSOM(CSS Object Model)というツリーにまとめられる

2. レンダーツリーを構築
 1でできたDOMツリー、CSSOMを組み合わせレンダーツリーが作成されます。
 ここでは、レンダリング対象の要素のみ入っている。
 そのため、画面を構成しない下記のものはこちらには入っていない

- meta情報
- display: none など

3. レンダーツリーをレイアウト

- 2のレンダーツリーを元に、位置・サイズを計算し正確なCSS情報を計算
- そして、正確なCSSをHTMLに当てていく。
 ex. z-indexの重ね順などが整理されていく

4. レンダーツリーをペイント

- 6番のコンポーネントにあった`UI Backend`を使用して各ノードを画面上にペイントしていく。
- 重ね順に従って、背景から前面へと描画されていく。

#### 2〜4は全て終わってから描画されるのではなく、できたものからどんどん描画を進めていく。

 

## レンダリングエンジンが解析しやすい書き方

ChatGPTにちょっと聞いてみました。

- 適切なHTML

 - ほとんどdivで囲むのではなく、ヘッダーなら `headerタグ`, フッターなら `footerタグ`, など役割にあったタグをちゃんと使用する
 - 深い階層にしない

 ```html:index.html
 <div>
 <ul>
 <li>
 <a href="https://google.com"> googleへ </a>
 </li>
 </ul>
 </div>
 ```

 このコードより、

 ```html:index.html
 <li>
 <a href="https://google.com"> googleへ </a>
 </li>
 ```

 このように短いネストの方が解析しやすいらしい

 - 非推奨タグは使用しない

 

- CSSを分離

 - HTMLに直書きするのではなくちゃんと別ファイルに分離する

- 効率的なJavascript

 - 不要なJavascriptは読み込まないようにして実行されないようにする

- キャッシュコントロール

 - 適切なキャッシュコントロールヘッダーを設定する

- レスポンシブ
 - メディアクエリを使用しレスポンシブデザインを書いておく

## まとめ

簡単に書いてみましたので、本当はもっといろいろなことが内部で行われて画面が見えるようになっております。 
URLを叩いてすぐ画面が出てくるのに、裏側で色々なことが一瞬でやってると思うとすごいなーという感じですね！

#### 引用

https://web.dev/articles/howbrowserswork?hl=ja

https://dev.to/itswillt/the-components-of-a-browser-23mn

検索ブラウザの内部構造を見てみる

当ブログにリンクカードを実装しました！

https://github.com/markdown-it/markdown-it

直書きのURLに対してリンクカードを生成するようにしております。 
なかなか調べても情報が少なかったので、 
catnoseさんのzenn-editorのコードで勉強させていただきました。

https://github.com/zenn-dev/zenn-editor/blob/canary/packages/zenn-markdown-html/src/utils/md-linkify-to-card.ts

誰かの参考にしていただけたら嬉しいです！

 

## 使用するもの

- markdown-it
 - markdownからhtmlにパースする
- [open-graph-scraper](https://www.npmjs.com/package/open-graph-scraper)
 - OGP情報を簡単にスクレイピングして取得できるライブラリです

 

## ロジック(このサイト)

1. マークダウンデータから直書きリンクを探す
2. OGP情報を取得
3. markdown-it用のプラグインを自作する
4. markdown-itでのパース時に、自作したプラグインを読みこむ
5. 1,2,4をサーバー側で読み込む

 

## 1. マークダウンデータから直書きリンクを探す

このブログはマークダウンデータをDBに保存しています。 
データから直書きリンクを正規表現で抽出し配列に入れます。

```typescript
export function extractLinks(md: string) {
 const regFloatLink =
 /(?<!\()https?:\/\/[-_.!~*\\'()a-zA-Z0-9;\\/?:\\@&=+\\$,%#]+/g;
 const floatLinks = md.match(regFloatLink);

 return floatLinks ?? [];
}
```

 

## 2. OGP情報を取得

1で取得したリンクを元に、open-graph-scraperを使用し直書きリンクからOGP情報を取得します。 
これは、リンクカードを表示するときのテキストやfavicon, ogp画像を使用するためです。

```typescript
export async function getOgpData(
 autolink: string[],
): Promise<OgpDataRes[] | undefined> {
 let res: any = [];

 if (autolink.length === 0) {
 return res;
 }
 if (!autolink) return;

 await Promise.all(
 autolink.map(async (link) => {
 const { error, html, result, response } = await ogs({
 url: link,
 timeout: 5000,
 });

 // エラー時とデータ取得失敗の際
 if (error || !result.success) {
 if (error) {
 console.error('ogp取得エラー1', error);
 } else if (!result.success) {
 console.error('ogp取得エラー2', result.success);
 }

 return response;
 }

 // OGPデータ取得に成功;
 res.push(result);
 }),
 );

 return res;
}
```

 

無事、OGPデータを取得できると下記のように情報が返ってきます。 
いくつか情報が返ってきますが、 
このサイトで使用しているのは下記になります。

- ogSiteName
- ogTitle
- favicon
- ogImageのurl, alt

 

## 3. markdown-it用のプラグインを自作する

プラグインの作成に関しては、下記の記事を参考にさせていただきました。

https://zenn.dev/mkizka/articles/9d4954d83b8862

```typescript
export function linkCard(md: MarkdownIt, ogpDatas: OgpDataRes[]) {
 md.core.ruler.after('replacements', 'link_card', ({ tokens }) => {
 // https://から始まるリンクのみが対象
 const linkRegex = /^https:\/\//;

 tokens.forEach((token, i) => {
 // 直書きリンクはinlineのchildrenにのみ存在するのでそれ以外は除外
 if (token.type !== 'inline') return;
 if (!token.children) return;

 // リンクカードの生成
 token.children.forEach((child) => {
 if (
 child.content &&
 child.type === 'text' &&
 child.markup !== 'linkify' &&
 linkRegex.test(child.content)
 ) {
 // ogpDataのリンクと同じ場合htmlを生成する
 const ogpData = ogpDatas.find((data) => {
 return data.ogUrl === child.content;
 });
 console.log(ogpData);

 if (ogpData) {
 child.content = `
 <section class="md-link-card">
 <div class="og-text">
 <h1>${ogpData.ogTitle}</h1>
 <div class="og-text__icon">
 ${
 ogpData.favicon
 ? `<img src="${ogpData.favicon ?? 'リンクカードのfaviconです'}" />`
 : ``
 }
 ${ogpData.ogSiteName}
 </div>
 </div>
 <div class="og-img">
 <img src="${ogpData.ogImage[0].url}" alt="${ogpData.ogImage[0].alt ?? 'リンクカードのイメージです'}">
 </div>
 </section>
 `;
 child.type = 'html_block';
 }
 }
 });
 });
 });

 return true;
}
```

 

## 4.markdown-itでのパース時に、自作したプラグインを読みこむ

3で作成した`linkCard`プラグインをパース時に動くように読み込みます。

```typescript
import MarkdownIt from 'markdown-it';
import { linkCard } from './linkCard';

export function changeHtml(markdown: string, ogpDatas?: any) {
 // オプションが別途必要な場合はlinkifyの後に書けばOK
 const md: MarkdownIt = MarkdownIt({
 html: true,
 linkify: true,
 });

 // 自作プラグインを読み込み取得したOGP情報を渡す
 if (ogpDatas) {
 md.use(linkCard, ogpDatas);
 }

 return md.render(markdown);
}
```

 

## 5. 1,2,4をサーバー側で読み込む

これで準備ができたので、Next.jsの`getStaticProps`で実行します。 
SSR, ISRでも同様で大丈夫だと思います。

```typescript
export const getStaticProps: GetStaticProps = async () => {
 // response.notice.contentの中にマークダウンデータが入っています。

 --- 省略 ---

 // リンクカード生成
 const floatLink = extractLinks(response.notice.content ?? '');
 const ogpDatas = await getOgpData(floatLink);

 // マークダウンをhtmlに変換
 const htmlContent = changeHtml(response.notice.content ?? '', ogpDatas);

 --- 省略 ---
}
```

 

あとはCSSで装飾すればリンクカードが完成します！ 
当ブログはGithubで公開しておりますので、 
コードの全般は下記のリンクカードからご覧いただければと思います。

 

https://github.com/zaki-app/zaki-dev

【Next.js】markdown-itでリンクカードを作成する

このブログを書くにあたって、 
zaki-dev内のマークダウンをまとめる。

## 見出し

```markdown
# h1

## h2

### h3

#### h4

##### h5
```

# h1です

## h2です

### h3です

#### h4です

##### h5です

## リスト

```markdown
- リスト
 - サブのリスト
```

- リスト
 - サブのリスト

```
1. １番目
2. 2番目
```

1. 1番目
2. 2番目

## リンク

今後直書きは`リンクカード`を作りたい！

https://zaki-dev.com/

[zaki-dev](https://zaki-dev.com/)

## テーブル

| 　 | Head | Head |
| ---- | ---- | ---- |
| Text | Text | Text |
| Text | Text | Text |

## テキストの装飾

```markdown
_イタリック_
**太字**
~~見せたくない~~
強調したいところ`/foo/baar`
```

_イタリック_ 
**太字** 
~~見せたくない~~ 
強調したいところ`/foo/baar`

# code

highlight.jsを使用しています。

```javascript
const likeMusic = '緑黄色社会';
```

## 隠しておく

<details><summary>折りたたみです</summary>
```markdown
見つかっちゃった🙃
```
</details>

## 引用

> 引用する素敵なページ
>
> > ネストされた引用

マークダウンチートシート

最近アウトプットしないとなと感じてきたので、 
技術系のブログサイトを作りました！

 

### なんでやるか？

- エンジニアになってから色々やってきたけど、 
 毎回同じことを調べて同じ記事を見てたりで、 
 時間がもったいないなと思ったので、 
 やって成功したロジックや勉強したこととかをどこかに残しておきたかった。

- 24時間365日運用できる気軽なものが欲しかった。
- 気軽に技術記事を書きたかった

 

### 技術スタック

このブログはNext.jsで開発しました。 
記事はVscodeで書きたかったので、 
別リポジトリでSupabaseに保存するようにしてます。 
このブログで使用している技術なども記事にできたらいいなと思ってます！

あと、このブログはGithubでパブリックにしてます。

https://github.com/zaki-app/zaki-dev

 

### お問い合わせ

不具合やその他のお問い合わせは下記のページからよろしくお願いします。

[お問い合わせ](https://zaki-dev.com/contacts)

Zaki-dev

お知らせ

カテゴリー

新着記事

GKEでクラスターの作成から削除まで

【GCP】 Cloud Functionsで速度比較をしてみた

【GCP】 gloud cliをインストールする

【システム設計1】負荷分散アルゴリズムについて考えてみる

主要なクラウドサービスプロバイダをまとめる

当ブログにSentryを導入した【Next.js page router】

【Typescript】Remixクイックスタート

検索ブラウザの内部構造を見てみる

【Next.js】markdown-itでリンクカードを作成する

マークダウンチートシート

お知らせ

カテゴリー

新着記事

GKEでクラスターの作成から削除まで

【GCP】 Cloud Functionsで速度比較をしてみた

【GCP】 gloud cliをインストールする

【システム設計1】 負荷分散アルゴリズムについて考えてみる

主要なクラウドサービスプロバイダをまとめる

当ブログにSentryを導入した【Next.js page router】

【Typescript】Remixクイックスタート

検索ブラウザの内部構造を見てみる

【Next.js】markdown-itでリンクカードを作成する

マークダウンチートシート

【システム設計1】負荷分散アルゴリズムについて考えてみる