ブログトップ

公開日:

更新日:

13 min read

技術革新

CloudflareでGmailを使ってメール送信を実装する 開発環境編

Cloudflare Workers Gmail API ウェブ開発 JavaScript OAuth 2.0
CloudflareでGmailを使ってメール送信を実装する 開発環境編のイメージ

Cloudflareってなに？

数年前、サーバーレス技術なる単語を目にした。サーバーを使わずにウェブを構築すると言う。

意味が分からん。

こちとらSVR4の時代からUNIXを使っているのだ。サーバーがないとウェブは成り立たんだろう。ということで、当時は無視した。

あれから数年後、WordPressに嫌気がさした私は静的サイトジェネレーターを探し始めた。そして、Astroと出会った。

さらに、無料で使える都合のいいウェブサーバーを探していたら、Cloudflare Pagesを見つけた。なんでもどんなにページアクセスが増えても、対応できるらしい。 そういや、Akamaiっつーのがあったな、と思い出した。それも「分散負荷をする」という印象しかない。具体的にはどう実現しているのか、ラウンドロビンでDNSを返すだけだろうか、調べたこともない。いい機会なので、AIに調べさせよう。

Akamaiの負荷分散技術について、以下のように簡潔にまとめることができます:

  1. グローバルサーバー負荷分散 (GSLB): 世界中に分散配置された35万台以上のサーバーを活用し、ユーザーに最も近いサーバーにトラフィックを振り分けます。

  2. エッジコンピューティング: ユーザーに近いエッジサーバーで処理を行うことで、レイテンシーを低減し、オリジンサーバーの負荷を軽減します。

  3. インテリジェントな負荷分散アルゴリズム: ネットワークレイテンシー、地理的近接性、サーバーステータス、現在のネットワーク状態などを考慮して最適なサーバーを選択します。

  4. マルチクラウド対応: 様々なクラウドプロバイダーやデータセンターにサーバーを配置し、柔軟な負荷分散を実現します。

  5. アプリケーションレベルの負荷分散: HTTP/HTTPSトラフィックの内容に基づいて、最適なサーバーにリクエストを振り分けます。

  6. 自動スケーリング: トラフィック量に応じて自動的にリソースを調整し、効率的な負荷分散を行います。

これらの技術により、Akamaiは高可用性、高パフォーマンス、そしてグローバルスケールでの効率的なコンテンツデリバリーを実現しています。

AkamaiとCloudfkareは似たようなものではないのか？違いを聞いてみた。

Cloudflareとakamaiの主な違いを簡潔にまとめると以下のようになります:

  1. ネットワーク規模:

    • Akamaiは世界最大のCDNで、35万台以上のサーバーを持つ。
    • Cloudflareは300以上の都市に展開し、228 Tbps以上のネットワーク容量を持つ。

  2. サービス提供:

    • Akamaiは高度なエンタープライズ向けソリューションに強み。
    • Cloudflareは使いやすさとコスト効率に優れ、中小企業にも適している。

  3. 価格設定:

    • Akamaiは一般的に高価だが、高度な機能を提供。
    • Cloudflareはより手頃な価格設定で、無料プランも提供。

  4. エッジコンピューティング:

    • AkamaiはEdgeWorkersを通じて高度なエッジ処理を提供。
    • CloudflareはWorkers platformを通じてエッジコンピューティングを提供。

  5. セキュリティ:

    • 両社とも強力なDDoS保護を提供するが、Akamaiはより高度なセキュリティ機能を持つ。

  6. 導入の容易さ:

    • Cloudflareは簡単に設定でき、即座に利用開始可能。
    • Akamaiはより複雑な設定が必要だが、カスタマイズ性が高い。

  7. 顧客サポート:

    • Akamaiは高評価のマネージドサービスを提供。
    • Cloudflareは自己管理型のサービスに強み。

両社とも優れたCDNサービスを提供していますが、Akamaiはより高度な機能と大規模企業向けのソリューションに強みがあり、Cloudflareは使いやすさとコスト効率に優れています。

つまり、負荷が増えたら世界中にページを増殖させて、ユーザーに最も近いサーバーにトラフィックを振り分けるということだろうか。なるほど、なるほど。 確かにサーバーレスだ。サーバーが不要なのではなく、自前でサーバーを用意しなくていいから、サーバーレスなんだな。ネーミングが無洗米のようだ。これを使えばDockerだとかKubernetesだという話もなくなるじゃないか。

Cloudflare Workersとは？

Cloudflare Workersとは、Cloudflareが提供する機能で、リクエストを処理するサーバーレス関数を作成できる。 Cloudflare Pagesは表示（フロントエンド）しかできないので、受け側の動的処理（バックエンド）をworkersが担当するのだな。 これも同じようにサーバーレスというわけだ。データベースやストレージなど使わなければ、この仕組みで十分だろう。

え？使える？

Cloudflare Workersが提供するデータベースとストレージのオプションについて、以下のように簡潔にまとめることができます:

  1. D1:

    • SQLiteベースのサーバーレスSQLデータベース
    • Workersと緊密に統合されている
    • 最大10GB、50,000個のデータベースをサポート
    • Time Travel機能で過去30日間のデータを分単位でロールバック可能

  2. KV (Key-Value):

    • 低レイテンシーのキーバリューストア
    • グローバルに分散され、エッジで読み取り可能

  3. Durable Objects:

    • 一貫性のある状態を維持できるオブジェクトストレージ
    • 分散システムでの状態管理に適している

  4. R2:

    • S3互換のオブジェクトストレージ
    • 大容量ファイルの保存に適している

  5. Hyperdrive:

    • 既存のPostgreSQLデータベースへの高速接続を提供
    • コネクションプールを管理し、レイテンシーを削減

これらのオプションにより、Cloudflare Workersは様々なデータ保存と管理のニーズに対応できます。D1はSQLデータベースとしての機能を提供し、KVは高速なキーバリューアクセスを、Durable Objectsは状態管理を、R2は大容量ストレージを、そしてHyperdriveは既存のデータベースとの統合を可能にします。

素晴らしい！

wranglerに関する注意

Wranglerの使用方法が変更されました。以前の方法と現在推奨される方法を比較すると:

以前の方法:

  1. Wranglerをグローバルにインストール 
       npm install -g wrangler
  2. initコマンドでプロジェクトを初期化 
       wrangler init my-project

現在推奨される方法:

  1. npm createコマンドを使用してプロジェクトを作成。ディレクトリ名はコマンドを実行すると聞かれるそうだ。wranglerもプロジェクトにインストールされる。 
       npm create cloudflare@latest

この変更には以下のような利点があります:

  1. プロジェクトごとに異なるバージョンのWranglerを使用できる
  2. グローバルインストールによる潜在的な問題を回避できる
  3. npm createコマンドにより、より柔軟で機能的なセットアッププロセスが提供される

ただし、グローバルインストールされたWranglerを使用することも依然として可能です。しかし、Cloudflareは各プロジェクトでローカルにWranglerをインストールすることを推奨しています。

この新しいアプローチにより、プロジェクト管理がより柔軟になり、バージョン管理も容易になります。

Cloudflare Workersの言語はnode.jsもどき

workerにはnode.jsを使うのか。TypeScriptも使えるのか。いずれも使ってみたいと思っていた。JavaScriptなら25年前から使っている。 あの頃はデバッガーもなくて、1000行以上のバニラJSを、ひたすらalertでデバッグしていた。よくシステムができたものだ。 しかしJavaScriptは型定義が無くて、それでエラーが頻発して苦しんだ。もともと私はCやC++を長年使ってきたので、高級言語の曖昧な型定義が苦手だった。

そもそも動的な型付けによる利便性よりも、厳密な型定義がないデメリットの方が個人的にははるかに大きい。pythonですら型ヒントを実装したくらいだ。 動的な変更ならポインタで受け取ってキャストでもすればいいだろう、とついつい考えてしまう。 TypeScriptはその辺をがっつり補ってくれると聞いているので、非常に興味があったのだ。

Cloudflare Workersにはライブラリの制約があり、ネイティブなNode.jsモジュールは使用できないため、ブラウザ互換のコードを書く必要がある。 node.jsはプロジェクトごとにインストールするらしい。こうすることで、バージョンの依存関係をプロジェクトごとに管理できる。他のプロジェクトに左右されないので、安心だ。

Cloudflare Pages アプリケーションとは？

workerを作成しようとして気づいた。Pages アプリケーションなるものがある。これは何だろうか。

Cloudflare Pagesアプリケーションとは、Cloudflare Pagesプラットフォーム上で動作するウェブアプリケーションのことを指します。 Cloudflare Pagesアプリケーションは、開発者が複雑なインフラストラクチャを管理することなく、高性能でスケーラブルなウェブアプリケーションを構築・デプロイできるようにすることを目的としています。 Pages Functionsは、Cloudflare Pagesアプリケーションを拡張する機能です。Pages Functionsは、Pagesプロジェクト内に /functions ディレクトリを作成することで利用できます。

つまり、Pages Functionsを使えば、メール送信のサーバーサイド処理をPagesアプリケーション内で実装できるということだろう。

Cloudflare Pagesアプリケーション開発の準備

会社のサイトはastroを使用しているので、astroの設定も交えて説明していく。なぜなら、このブログは私の備忘録兼マニュアルになっているので、しっかりと書かないと、後で別のサイトを構築するときに分からなくなるからだ。

  1. 大前提

    • Cloudflareのアカウントを作成し、Pagesにastroで構築したウェブサイトのGitHubリポジトリを連携させて、デプロイできるようにします。

  2. 必要なパッケージのインストール:

    • プロジェクトのルートディレクトリに移動して、以下のコマンドを実行します。このときにwranlgerもインストールされる。
       npm install --save-dev typescript @cloudflare/workers-types

  3. 必要なファイルの作成:

    • astroのプロジェクト内に functions ディレクトリを作成します。
    • このディレクトリ内に、メール送信のサーバーサイド処理を実装するファイルを作成します。
       your-astro-project/
├── src/
│   └── pages/
│       └── index.astro
├── functions/
│   ├── otoiawase-form.ts  ※今回作成するファイル
│   └── tsconfig.json
├── public/
├── astro.config.mjs
├── package.json
└── wrangler.toml

    コマンド:

       mkdir functions
touch functions/otoiawase-form.ts functions/tsconfig.json wrangler.toml

  4. 必要な設定:

    • functions/tsconfig.jsonに下記を追加する。
       {
	"compilerOptions": {
		"target": "esnext",
		"module": "esnext",
		"lib": ["esnext"],
		"types": ["@cloudflare/workers-types"],
		"sourceMap": true
	}
}
    • tsconfig.jsonに下記を追加する。
       {
	"include": ["src/**/*"],
	"exclude": ["functions/**/*"]
}

  5. 実装:

    • 実はすでにworkerで実装してしまったのだが、せっかくなのでPages Functionsで実装することにした。
    • 次回以降の記事で詳しく解説する。