クラウドの原稿一式

ていうかGoogle Cloudってこんなにお客さんがいるんだね！
👉 Google Cloud のお客様
なんか有名なゲーム会社とかいろいろ、すっごいの…
想像以上でした💦
でもMicrosoftのクラウドのほうがもっと広がってるよ？

あ、そうそう…日本政府が「クラウド・バイ・デフォルト原則」なんてものを打ち出すくらい、クラウドサービスは身近なものとなっています。
アジリティ・スケーラビリティ・コストの３点において、とても有利なんです。

アジリティは迅速性。
クラウドは仮想化技術のおかげで、導入決定から利用開始までのスピードが早いんです。
仮想化というのは、物理的な機器の上に論理的なレイヤを置いて利用する技術のことですね。（Compute Engine）

スケーラビリティは柔軟性。
リソースを自在に増やしたり減らしたりできる性質のことですが、次の用語が分かりやすいかもしれません。

オートスケーリング：アクセスの増減に応じて自動でサーバーの数を増減させること

• スケールアウト：負荷が高まった時にサーバーの数を増やして性能を上げること

• スケールイン：負荷が下がり、サーバーの数を減らすこと

→ 水平スケーリング：スケールアウトやスケールインによってスケーラビリティを調整すること

• スケールアップ：サーバーの数を増やすのではなく、CPUやメモリなどのリソースの割り当てを増やして性能を上げること

• スケールダウン：負荷が下がり、リソースの割り当てを減らすこと

→ 垂直スケーリング：スケールアップやスケールダウンによってスケーラビリティを調整すること

コストはセクションを区切って書いてみます。

クラウドネイティブとは、最初からクラウド環境でアプリケーションを実行したり、ソフトウェアを開発したりすることを前提とした考え方のことです。
物理サーバーを使わず、クラウドの利点を最大限に活用することを目指すあり方と言えば良いでしょうか。
クラウドネイティブの特徴として、次の3点が挙げられます。

1. スケーラビリティ：必要に応じてリソースを簡単に増減できる

2. 柔軟性：アプリケーションの更新や修正が迅速に行える。

3. コスト効率：物理インフラの維持費が不要で、運用コストを削減できる。

私が作っているfein's portalなんか思いっきりクラウドネイティブですよ。
ていうかそれ以外の手法でやるつもりないと言いますか。
現在はまだ大規模なものではありませんが、将来的には、次のような技術を使って拡張していくつもりですよ？

• コンテナ：アプリケーションを軽量な仮想環境で実行する技術。

• マイクロサービス：アプリケーションを小さな独立したサービスに分割するアーキテクチャ。

• サービスメッシュ：マイクロサービス間の通信を管理するソフトウェアレイヤー。

代表的なものをささっと挙げただけだけどね。
全てではないにしても、このWebページで詳しく書いていきます。
このようなクラウドネイティブのアプローチを採用することで、迅速かつ効率的にいろいろ作れるようになるんですよ。

Eロンが「X」とか言って粗暴な振る舞いをし始めた途端、私は速攻でこのサイトを作り上げたでしょう？
こういうのなんか、クラウドならではだと思いますね。
逃げ足の速さはアナデン界隈でトップだったかと😆ww

トランスフォーメーションは変革と訳されることが多く、Googleに限らずクラウドに関する文書ではいろんなところで目にします。
企業や組織がデジタル技術を活用してビジネスプロセスやサービスを大幅に改善・革新することを指すのですが、最近やたらと耳にするデジタルトランスフォーメーション（DX）も、その考え方の一つでしょう。

オンプレミスのシステムをクラウドに移行し、柔軟性とスケーラビリティを向上させつつ、データ分析やAIを用いて、ビジネスの意思決定を迅速かつ的確に行う。
そしてAIや機械学習を活用して、業務の効率化と自動化を図っていく。

Google Cloudは、これらの変革を支援するためのプラットフォームとして「トランスフォーメーションクラウド」を提供しているということになります。
企業はデータの民主化、アプリケーションのモダナイゼーション、信頼できるトランザクションを通じて、デジタルトランスフォーメーションを促進していくことが可能となるでしょう。─ ここで言う「民主化」とは、SNSで話題になっているところの、[生成AIによる画像生成機能が才能の民主化である]などという話ではありません。 ─

トランスフォーメーションは、デジタル技術を活用して競争力を高めるための重要な概念なんですよね。

「アプリケーションのモダナイゼーション」と読み替えてよろしいかと。
既存のアプリケーションを最新の技術やアーキテクチャに移行・更新するプロセスのことですよ。

アプリケーションをクラウド環境に最適化し、Google Kubernetes Engine（GKE）やAnthosなどのプラットフォームを活用します。
こういうのをクラウドネイティブ化と呼ぶのです。
マイクロサービスアーキテクチャだってそうですよね。
大規模なモノリシックアプリケーションを小さな独立したサービスに分割し、管理しやすく構築し直します。
継続的インテグレーションとデリバリーができるようにした上で、デプロイメントの頻度を上げようとCI/CDパイプラインを構築したりとか。
Apigeeみたいなツールを使ってAPIの管理とセキュリティを強化するとか。

もちろんアプリケーションのパフォーマンス、スケーラビリティ、セキュリティが向上し、運用コストの削減や市場投入までの時間短縮が可能になります。
するとどうなるかというと、すばやく市場の変化に対応し、競争力が高まるということになるのです。

総合的なコスト：TCO(Total Cost of Ownership)で見ると、クラウドの方が安いです。
簡単な話で、自分でぜーんぶサーバー等を準備するより、使った分だけお支払いする方が安上がりってことですよ。
TCO(Total Cost of Ownership)は総所有コスト。
ROI(Return on Investment)は投資利益率。
計算式は次のとおりです。

ROI(%表記)=利益÷投資金額×100

例えばTCOが10000円のシステムで、17000円の利益が出た場合、ROIは17000÷10000×100＝170%となります。
この170%がROIです。
クラウドを使うことで初期費用を押さえつつ、効率よい運用ができて、ROIが最大化できるということです。
利益を維持したままTCOが下がれば、ROIが上がりますよね。
クラウドはオンプレミスに比べてTCOが小さいです。
普段使っているシステムのTCOを押さえることは、ROIの最大化に繋がります。
そのためにはぜひともTCO、すなわち総所有コストの把握が必要となるのです。

別の言葉も少し紹介します。
CapEx(Capital Expendditure)は資本的支出。
設備投資のことです。
賃借対照表の資産であり、減価償却されます。
OpEx(Operating Expense)は経費的支出。
そのままの意味で、経費とされる支出です。
このOpExがクラウドサービスの支払いに当たります。

ここでコストについて少し細かくお話したのは、長期的に運用する前提に立った場合、TCOすなわちITの導入・維持にかかるすべての費用を可能な限り抑えたほうが良いという視点からです。
趣味であっても安いは正義でしょ？
でも、ただ単に安いは正義というより、クラウドの経費という意味で、このような考え方に基づいていますよというお話です。

本来であれば、Google sitesは無料で使えるけどね。
しかし、万が一のトラブルまで視野に入れて年間2500円くらいはお支払いしても良いという判断なんです。
クラウドストレージも100GBまで使えます。

コストについて書く前に、Google Cloudには「クォータ管理」というものがあります。
Google Cloudは、いろんなユーザーが共通のクラウド上のリソースを利用する、いわばマルチテナントです。
当然そのクラウドサービスには割り当てがあります。
ある一人のユーザーが負荷試験のようなことを行い大量のリソースを使ってしまうと、他のユーザーが快適に使えないかもしれない。
Google Cloud使用時、割り当てに抵触しないかを定期的に確認することが大切です。
必要なら、その分に応じて増量リクエストを行うことができます。

話を戻すと、Google Cloudの利用料金は原則として従量課金です。
サービスごとに課金方式が定められています。
よってITコストが毎月変動するということになります。

私が使っている個人用のGoogle Oneはサブスク形式なんですけどね。

Google Cloudではシステムの管理単位ごとにプロジェクトを分割し、管理責任者を定め、コスト管理の責任も持たせることで、管理責任を分散させる方式が良しとされています。
その形がクラウド環境の運用をスケールするためのベストプラクティスだからです。

しかし、各プロジェクトごとに管理責任を持たせると言っても、具体的にどのくらいの請求が来るのか計算する必要があります。
「Google Cloud Pricing Calculator」は、利用料金の見積もりができるツールとなっています。
また「Cloud Billingレポート」にて、現在の課金額をプロジェクトやサービスごとの明細も含めて確認可能です。
これらはもちろんクラウドサービスとして提供されているもので、ブラウザで利用できます。
Google Cloudでは請求先アカウントというものがあって、このアカウントごとに請求書が発行されます。

このように管理責任者のもとでCloud Billingレポートを各チームが確認し、各部門の連携を強化することでコスト最適化が実施可能となります。
予算アラート機能もあるため、必要なら請求額が一定の比率になった時にアラートメールを受け取ればうっかりミスも防げます。

私が使っているGoogle Oneと同じように、Google Cloudにもサポートがあります。
注目すべきはプレミアムサポートですかね。
最速の応答時間が保証され、TAM（Technical Account Manager：専任エンジニア）までアサインされます。
このプレミアムサポートを含めて、プランとしては次の４つがあります。

ベーシックサポート：無償、平日日中帯のみ
利用料金に関する問い合わせのみ
初回応答時間は保証なし

スタンダードサポート：有償、平日日中帯のみ
技術サポート（英語）
初回応答時間は４時間

エンハンストサポート：有償、24時間365日
技術サポート（日本語を含む複数言語）
初回応答時間は１時間

プレミアムサポート：有償、24時間365日
技術サポートに加え、TAM(Technical Account Manager：専任エンジニア)による個別対応
初回応答時間は15分

続いて、具体的な流れについても触れておきましょう。
まず、Google Cloudのサポートチームに対して技術的な問題や質問を報告するプロセスがあります。

1. Google Cloud サポートポータルにアクセス：サポートポータルにログインします。

2. サポートケースを作成：「サポートケースを作成」ボタンをクリックします。

3. 詳細を入力：問題の内容、影響範囲、優先度などの詳細を入力します。

4. 送信：必要な情報を入力したら、ケースを送信します。

こうして、Googleのサポートチームが問題を確認、対応を開始することになります。
既に作成されたサポートケースの優先度を上げることもできます。
問題が重大であり、迅速な対応が必要な場合もあるからです。
エスカレーションを行うことで、より高いレベルのサポートが得られることがあります。

1. サポートケースを開く：既存のサポートケースをサポートポータルで開きます。

2. エスカレーションを選択：ケースのオプションから「エスカレーション」を選択します。

3. 理由を入力：なぜエスカレーションが必要か、その理由を入力します。

4. 送信：エスカレーションリクエストを送信します。

できればサポートケースを作成することなく使いたいですけどね。
Google Oneのサポートをまだ使ったことはありませんが、いずれ何かのトラブルがあった時には問い合わせを行うこともあるかもしれません。

本格的にGoogle Cloudの話へ突入する前に、ちょっと分かりにくいタイプのIT用語について見ていきましょう。
IT用語なんて無数にあるけど、なんとなく推測できるものと、なんのことだかさっぱり分からないものがあると思うんです。
ここに書いていくのは、私が学生時代に「分かりにくい…」と感じていた言葉ですよ。
このWebページを作るのに使っている昔のノートには、これらの言葉についての説明がびっしりとメモしてありました😅

システムやサービスが障害を検出した際に、自動的にバックアップシステムに切り替えるプロセスを指します。
サービスの中断を最小限に抑え、可用性を維持するのはとても大切なことですよ。
システムの信頼性と耐障害性を向上させるための重要な機能が、フェイルオーバーなのです。

まずは分かりやすいCloud SQLのフェイルオーバーから。
Cloud SQLでは、プライマリインスタンスが応答しなくなった場合、自動的にスタンバイインスタンスに切り替わります。
データの損失を防ぎつつ、ダウンタイムを最小限に抑えるために重要です。
また、ネットワーク負荷分散においてもフェイルオーバーの考え方があります。
特定のインスタンスグループがしきい値を下回った場合、トラフィックが自動的に別のインスタンスグループに切り替わります。

Google Cloudに限らず、およそいろんなヘルプページでよく見る言葉です。
この「インテリジェンス」というのは、Twitterでよく見るところの「頭が良いフリをする」ということではありません😅
そうではなく、主にセキュリティやデータ分析に関連する高度な機能を指すのです。
いくつか具体例を書いてみましょう。

＜セキュリティインテリジェンスの事例＞

• 脅威インテリジェンス：AIを活用してサイバー脅威を検出し、分析する機能です。Mandiant Threat Intelligenceみたいなシステムを使い、最新の脅威情報を知りつつ組織のセキュリティを強化します。

• Google Cloud の Security AI Workbench：AIを使って脅威の検出や対応を自動化し、セキュリティチームの負担を軽減できます。

AIを使ったセキュリティソリューションなんか素晴らしいと思いますよ？
「Duet AI」はセキュリティ運用を支援するAIツールで、脅威の検出や対応を効率化できます。
「Google Threat Intelligence」も良いだろうね。Mandiantの知識やVirus Totalのデータを活用し、迅速に脅威を特定していきます。

＜データインテリジェンスの事例＞

• データ分析：大量のデータを迅速に分析し、洞察を得るためのツールやサービスを使います。これには、AIや機械学習を活用したデータ処理も含まれます。

そうですねー…
例えば、「最新のセキュリティインテリジェンスを活用することで、企業はサイバー攻撃からシステムを効果的に保護できます。」なんていう使い方をする言葉です。

これまたGoogle Cloudに限らず、およそITのヘルプページでよく見る言葉ですね。
Google sitesについてお話していることもあり、Google Cloudに絞りますか。
「エクスペリエンス」というのは、主にユーザーや開発者がGoogle Cloudのサービスを利用する際の体験のことです。
事例を挙げてみましょう。

＜開発者エクスペリエンス＞

• 効率的な開発環境：迅速かつ効率的に作業できるようにするためのツールやプラットフォーム。

• フロー状態の維持：集中して作業できるように、コンテキストスイッチを最小限に抑える設計。

• フィードバックループの短縮：開発サイクル中の反復プロセスを迅速に行えるようにする。

＜アナリティクス・エクスペリエンス＞

• データの価値化：データを迅速かつ簡単に分析し、価値ある洞察を得るためのツールやサービス。

• 統合された分析体験：分散されたデータを一元化し、効率的に管理・分析するためのプラットフォーム。

＜ユーザーエクスペリエンス＞

• 直感的なインターフェース：ユーザーが簡単に操作できるインターフェースを提供。

• 迅速なサポート：問題が発生した際に迅速に対応できるサポート体制。

ユーザーエクスペリエンスが一番目にするかな？
「ユーザーエクスペリエンスを向上させるために、直感的なインターフェースを設計しました。」なぁんてね。
Google Cloudもそうだし私が使っているGoogle Oneも、ユーザーや開発者にとってより使いやすく、効率的なプラットフォームを提供してくれています。
その中の一つがGoogle sitesということです。

いかにもITらしくなってきましたね。
クラウドサービスの運用に関わる作業をすべてクラウド提供事業者が管理・自動化することを指します。
Google Cloudであれば、もちろんGoogleが管理・自動化しているわけですよ。
具体的には、以下のような特徴があります。

• インフラ管理の自動化：
  サーバーのセットアップ、管理、パッチ適用、バックアップなどが自動的に行われます。
  例えば個人でノートパソコンを持ち、それをサーバー化して運用しているとしましょう。
  すると、これらの作業が丸ごと全てその個人の負荷となるのです。
  作業そのものはおもしろいし勉強にもなりますが、すでにその学習段階を完了したのであれば、何か強い興味でもない限り無理に実施しなくても良いものと考えます。

• 高可用性とスケーラビリティ：
  サービスのスケーリングや障害復旧が自動で行われるため、ユーザーはアプリケーションの開発や運用に集中できます。
  ハードディスクやメモリを増設したり、定期的に掃除をしたり。けっこうな手間となりますからね。

• コスト効率：
  実行時間や使用リソースに基づいて料金が発生するため、無駄なコストを抑えることができます。
  コストについては他セクションでもたっぷりお話をするので、ここではいいでしょう。

例えば、Google Kubernetes Engine (GKE) では、クラスタの管理やノードのスケーリングが自動化されており、ユーザーはアプリケーションのデプロイに専念できます。
Google Cloudの全機能を使いこなす必要はないにしても、ここらへんは私がやりたいことにも密接に関わってくるのです。

よく見る言葉ではあるけど、ここではGoogle Cloudを中心に考えていきます。
「ワークロード」とは、クラウド上で実行されるアプリケーションやサービスのことです。
コンピューティング、ストレージ、データベース、ネットワーキング、分析と機械学習、セキュリティとID管理…いろいろあります。
身近なところで例示するなら、Google OneのGoogleドライブやGoogleフォトはストレージの一種ですから、これをワークロードと呼んでも間違いではないわけです。
これらのワークロードは、Google Cloudの様々なサービスを組み合わせて構築・運用されます。
例えば、Webアプリケーションのワークロードは、App Engine、Cloud SQL、Cloud Storageなどを利用して構築されることが多いですよね。

余談ですが、もうWebサイトとWebアプリケーションは区別しなくてもよろしいかと。閲覧のみか否かという側面はありますが、どっちみち他サービスと連携するケースがほとんどだと思うので。

「ビジョンを明らかにした上でワークロードを考える」なんてよく聞く言い回しですが、何かしら実行当初から細かいビジョンが明らかになっているケースの方が少ないと思います。
こういうところもスモールスタートの原則に繋がるところがあるかもしれませんね。
Start → Build → Growの３段階に分けて考えることが多いのですが、例えばこのサイトはStartとBuildの間にあると言えるでしょう。

これはどちらかというとIT基礎用語ですよね。
上記にあるワークロードと合わせて考えると分かりやすいかもしれません。
例えば、「Google Cloudを利用して、ワークロードを効率的にデプロイすることで、スケーラブルで信頼性の高いアプリケーションを実現できます。」という文章があるとしましょう。

ワークロードとは上記通り、システムやネットワークが特定のタスクを完了するために必要な計算資源や処理能力のことです。
それはCPU、メモリ、ストレージ、ネットワーク帯域などのリソースを消費するアプリケーションやサービスの集まりです。
クラウドコンピューティングの文脈では、ワークロードは仮想マシン、コンテナ、データベース、アプリケーションなど、クラウドベースのリソースを消費するすべての要素を含みます。

デプロイというのは、開発したソフトウェアやアプリケーションを実際の運用環境に配置し、ユーザーが利用できる状態にすることです。

ゆえに上記の文章は、クラウドに仮想マシンやコンテナを効率的に設置して使えるようにすることで、柔軟性のあるアプリを作れますよってことですね。
でも意味が広いですよ。
なんかちょっと「あれ？？」って感じで使われている資料もよく見るし、それはそれで良いのではと思いますね。
IT業界は流れが速いから、定義が曖昧になっているのかもしれません。

リソースやサービスを設定し、利用可能な状態にするプロセスのことです。
クラウド環境を効率的に管理し、必要なリソースを迅速に準備する作業ですよね。
例えばユーザーのプロビジョニングという事例だと、新しいユーザーアカウントの作成や既存アカウントの管理が挙げれます。
ユーザーの自動プロビジョニングもそうです。
Google管理コンソールを通じてユーザー情報を自動的に同期することができます。
ユーザー設定ができたら、次はリソースのプロビジョニングですよ。
仮想マシン、ストレージ、ネットワークなどのクラウドリソースを設定し、必要な設定を行って利用可能にしなければなりません。
そして、具体的なサービスのプロビジョニングへ移ります。
データベースやアプリケーションなどのクラウドサービスを設定し、お客さんがそれらのサービスを使えるようにします。

要するにプロビジョニングというのは、あれこれの準備作業とざっくり解釈しても差し支えないでしょう。

これはクラウドというより、オンプレミスのバックアップ体制なんかの話でよく聞くかもね。
データのコピーを作成し、異なる場所に保存することです。
データの安全性と可用性及び耐障害性を向上させます。
Google Cloudの文脈に添わせるなら、次のようになるでしょう。

Cloud SQLのクロスリージョンレプリカ：
異なるリージョンにリードレプリカを作成する機能です。
特定のリージョンで障害が発生しても、他のリージョンでデータベースを利用し続けることができます。

Google Cloud Storage（GCS）へのレプリケーション：
データをGoogle Cloud Storageに複製することで、データのバックアップや災害復旧を容易にします。
これは難しくないですよ。
このサイト、fein's portalでも似たようなことやってます😆
ただ、このレベルなら数カ月に１回ペースでやればいいから、普通にGoogle Driveで手動作業してますけどね。

Persistent Diskの非同期レプリケーション：
Google Cloudのリージョン間でデータを非同期に複製し、Compute Engineワークロードの障害復旧を支援します。

クラウドはGoogleだけじゃありません。
Google Cloud・AWS・Microsoft Azure。
この３つは「３大メガクラウド」と呼ばれることもあります。

私がプライベートで使っているのはMicrosoft 365です。Microsoft Azureの親戚みたいに思ってもらえれば。
Azureより365のほうが安いんですよ。年間2440円。
「グラスタの場所一覧表（入手範囲別） 」にあるPDFは、Microsoft 365で作ったものをGoogle sitesに掲載している形になります。
※Microsoft 365も機能がすごいんですよね。もうまとめて把握し直そうと思って、先日Microsoft 365 Certified Fundamentalsという資格試験を受けてきました。

このように、２つ以上のクラウドサービスを利用する形態を「マルチクラウド」と呼びます。
ただ個人レベルで使っている分には、こんな呼称は大袈裟ですけどね。
ちなみに自社専用のデータセンターで運用するクラウドを利用する形態をプライベートクラウド。─ これが普通、オンプレミスと呼ばれているものです。 ─
インターネット経由で提供され、複数の顧客（組織）によって利用されるサービス形態はパブリッククラウド。
オンプレミスとクラウドサービスを併用する形態はハイブリッドクラウドと呼びます。

それぞれのサービスには異なる目的と機能があります。
GoogleもMicrosoftも似たようなことやってるんですよ。
ぶっちゃけどっちでも良いと思ってます。

＜Google Cloud＞
ここで主にお話ししているGoogle Cloudは、企業向けのクラウドコンピューティングサービスです。
データ管理、アプリケーションの開発とデプロイ、機械学習（AI/ML）などの機能が含まれます。
組織はGoogleのインフラストラクチャを利用して、スケーラブルで安全なアプリケーションを構築できます。

しかし、Google Cloudは個人でも利用できます。
法人でなくても、個人アカウントで簡単に登録して利用を開始することができるんですよね。
私が勉強してた時は両親にいろいろ初期設定やってもらったから詳しくアカウント作成方法を覚えてないのですが、現在は次のようになっています。

1. Google Cloudのウェブサイトにアクセスし、「無料で開始」をクリック。

2. Googleアカウントでログインし、本人確認のためのSMS認証を行う。

3. 支払い情報を入力するものの、無料トライアル期間中は料金は発生しない。

無料トライアルでは300ドル分のクレジットが提供され、これを使ってさまざまなGoogle Cloudサービスを試すことができます。

これに対するMicrosoftのサービスは「Microsoft Azure」です。
Azureもコンピューティング、ストレージ、データベース、機械学習、データ分析、セキュリティなど、幅広いクラウドサービスを提供していますね。
あるいは、両方ともアカウントを持っておいて、その場に応じてコスト管理をしながら使い分けるのが一番賢いかもしれません。

＜Google Workspace＞
Google Workspaceはビジネス向けの生産性ツールのセットです。─ 旧称は「G Suite」と呼ぶようですが、これに関しては詳しくは分かりません。─
Gmail、Googleドライブ、Googleドキュメント、Googleカレンダー、Google Meetなどがあり、通称の「Googleアカウント」と使用感はほぼ変わらないです。
ただ、独自ドメインのメールアドレスや高度な管理機能が提供されるところは注目すべきポイントです。

もちろんGoogle Workspaceも個人で利用できます。
個人事業主やフリーランスの方に関しては「Google Workspace Individual」というプランが提供されています。
大きいのはTBクラスのストレージが持てることですよ。
法人向けのGoogle Workspaceプランも個人で契約することが可能です。
例えば、Business StarterやBusiness Standardなどのプランがあり、それぞれのニーズに合わせて選択できるようになっています。

これに対するMicrosoftのサービスは「Microsoft 365」です。
私がずっとメインで使っているクラウドサービスで、とっても愛着があります。
Microsoft 365には、Word、Excel、PowerPoint、Outlook、Teamsなどのアプリケーションが含まれています。

＜Google One＞
Google Oneは、個人向けのクラウドストレージサービス。
このfein's portalで使っているサービスです。
Googleドライブ、Gmail、Googleフォトのストレージ容量を拡張するためのプランが提供されています。
100GBから最大30TBまでのストレージプランがあり、家族や友人と共有することも可能。
また、Google Oneのメンバーには、Googleのサポートや特典も提供されます。
とても便利ですよ？
Google One一つでほっとんどのパソコン関連機能が事足りるくらいです。
これに対するMicrosoftのサービスは「Microsoft OneDrive」ですが、これに関してはMicrosoft 365に含まれているので、説明は不要でしょう。

それぞれのプラットフォームで同様の機能を提供しており、異なるニーズに応じて設計されています。
目的に合わせて選択することが重要です。
この「AWS サービスや Azure サービスと Google Cloud を比較する」というページをご覧いただくと、Google・Microsoft・Amazonのどれを選んでも問題ないことを確認できるかと。
ニーズにもよるんだけどね。
ちなみにGoogle Cloudはデータの処理に長けていると言われます。
実際そうだと思うけど、似たようなことをAzureもAWSもできるから。
３社が競い合ってるのが良いんですよ。

クラウド提供事業者とユーザーは、それぞれ持つべき責任範囲が異なります。
このようにクラウド提供事業者とユーザーが責任を共有する考え方を責任共有モデルと言います。

────────
SaaS（サース）：ユーザーの責任範囲
コンテンツ
ID管理
セキュリティ設定
アプリケーション
ミドルウェア
OS
物理サーバー
物理ネットワーク
データセンター
────────

Google sitesはSaaSです。
だから、私のサイトであるfein's portalは、書く内容・Googleアカウントの管理・コメント制限などのセキュリティ設定について、私が責任を持っていることになります。
他のPaaSとIaaSについても書いておきましょう。

────────
PaaS（パース）：ユーザーの責任範囲
コンテンツ
ID管理
セキュリティ設定
アプリケーション
ミドルウェア
OS
物理サーバー
物理ネットワーク
データセンター
────────
IaaS（アイアース・イアース）：ユーザーの責任範囲
コンテンツ
ID管理
セキュリティ設定
アプリケーション
ミドルウェア
OS
物理サーバー
物理ネットワーク
データセンター

ITのオーバーヘッドを削減して効率化を図り、コアな活動に集中できるようにすることです。
ある任意の処理自体にかかる時間やリソースが「オーバーヘッド」と呼ばれますが、このオーバーヘッドが大きいと、システム全体の効率が低下します。

変なところに無駄な金と時間をかけず、コアな活動に集中する。
手段の目的化って、いろんなところで見かけますよ。
Webサイト制作が目的なのか。
それともコンテンツの掲示が目的なのか。

いくつかの用語を紹介しつつ、私が安住の地としてクラウドを選んだ理由の一部を書いてみます。
ここで言うクラウドとは、何もGoogleじゃなくても良いのですよ。
Microsoftでも良かった。─ 言い変えると、fein's portalはいつでも移転できるということです。手間は発生するけどね。─
ただ、こうして記述する上でのGoogle sitesの滑らかな動作が気に入ったんだよね。
ちなみにGoogle sitesは数年前にリニューアルされました。
まだ開発中の技術もありますが、Eロン率いるXなんかとは比べ物にならないほど堅牢ですよ。
私のいろんなゲーム思い出話などをずっと保管しておく場所として、相応しいと思います。

＜リプラットフォーム・リファクタリング・リホスト＞
リプラットフォーム(Replatform)とは、リホストに少し手を加えた方法です。アプリケーションのコア機能は変更せずに、クラウドのマネージドサービスを利用するようにアーキテクチャを一部変更します。
クラウドの利点を活かしつつ、移行の手間やコストを抑えることができます。

一方、リファクタリング(Refactoring)とは、アプリケーションをクラウドネイティブに最適化するために、コードやアーキテクチャを大幅に変更する方法です。
例えば、モノリシックなアプリケーションをマイクロサービスアーキテクチャに再設計することが含まれます。
スケーラビリティやパフォーマンスが向上しますが、移行には時間とコストがかかります。

リホスト(Rehost)は、一般的に「リフト＆シフト」とも呼ばれます。
アプリケーションやデータをそのままの形で新しい環境（通常はクラウド）に移行する方法です。
コードやアーキテクチャの変更は行わず、単にホスティング環境を変更するだけです。
移行が比較的簡単で迅速に行えるのが特徴です。

GoogleでもMicrosoftでも、はたまたAmazonでも良いから、いったん３大メガクラウドのどれかに基盤を作ってしまえば、仮に何かで雲行きが怪しくなっても融通が利くのですよ。
このサイトはホスティング環境を変更したと言ってもいいよね。
リホスト・リファクタリング・リプラットフォームに当てはまるわけではないけど、feinというアカウントをホスティングする環境を、XからGoogle sitesに変更しているのですから。
考え方としてはリホストに近いと思われる。

＜ロードバランシング＞
トラフィックを複数のサーバーに分散させることで、アプリケーションのパフォーマンスと信頼性を向上させるサービスです。
過負荷を防ぎ、応答時間を短縮し、システムの可用性を高めます。
ただでさえパワーが低いのに広告だらけでさ。
そういうWebサイト作成サービス、よく見ませんか？
表示も遅く、離脱率も上がってしまいます。

＜レジリエンスとフォールト トレラント＞

レジリエンスとは、システムやサービスが障害や攻撃に対して耐え、迅速に回復する能力のことです。
これには、データのバックアップ、冗長性、セキュリティ対策などが含まれます。

一方、フォールト トレラントとは、システムやアプリケーションが障害やエラーが発生しても、サービスを継続して提供できる能力です。
こちらでは、複数のゾーンやリージョンにリソースを分散配置することが含まれます。
フォールトトレランスと呼ばれることもありますね。
例えば、サーバーが故障した場合にバックアップサーバーが自動的に役割を引き継ぐことで、サービスが停止しないようにする仕組みが挙げられるでしょう。
この考え方は、システムの信頼性を高めるために非常に重要で、特に金融や医療などの重要なサービスで広く見られるものです。

ゾーンやリージョンに関しては別のセクションに説明があります。
クラウド上に構築していると言うだけで、いわば強固な石板に文字を書いているだけなんですよね。
ちょっとやそっとのことでは壊れません。

トラフィックを複数のコンピューティングリソースに分散させるサービスで、大規模で複雑なアプリケーションに対する高度なトラフィック管理と最適化を提供します。

アプリケーションの可用性、スケーラビリティ、パフォーマンスが向上します。
世界中のユーザーに低レイテンシーでサービスを提供できるグローバル負荷分散、トラフィック量に応じて自動的にリソースを増減するオートスケーリングができます。
バックエンドインスタンスが正常であるかどうか、継続的に監視するヘルスチェックも可能です。

一応、バックエンドインスタンスに説明しておきましょう。
クラウドやネットワークアーキテクチャの文脈でよく見る言葉ですね。
ユーザーからのリクエストを処理するためのサーバーやコンピュータのことです。
例えば、AWSのElastic Load Balancing(ELB)を例に挙げると、トラフィックを分散するために使用されるEC2インスタンスがバックエンドインスタンスと呼ばれることになります。
データの読み書きを行うデータベース連携なんかをしていますね。
こういう作業を実施するにあたり、複数のバックエンドインスタンスにトラフィックを分けることで、負荷分散ができるのです。

このfein's portal（広い意味でのウェブアプリケーション）でも、ユーザーがウェブページにアクセスすると、そのリクエストはロードバランサーを経由してバックエンドインスタンスに送られ、そこで処理されていると考えて良いわけです。

セキュリティも大切ですね。
Google CloudのCloud Load Balancingは、Cloud Armorとの統合によりDDoS保護やWAF機能を提供してくれます。
加えて、HTTP(S)、TCP、SSL、UDPなど複数のプロトコルをサポートしています。

正式には「Google Sites」です。
Googleが提供するウェブサイト作成ツールの名称で、複数のサイトを作成・管理できることを反映しています。
そう…私のサイトであるfein's portalは１つしかサイトがない状態なので、Google sitesの機能さえ十分に生かし切れていない段階なのです 。
まだゲーム以外の話題をSNSから切り離せていないから、独自ドメインである必要もありません。
こういうところも重要だよね。
まだ構想を進めている途中なのにいきなり力んだりすれば、後から動きにくくなります。

ホームページを作る作業を支援するものを「ウェブサイト作成ツール」と呼びます。
CMSとかいろんな用語があるけど、ひとまず検索するならウェブサイト作成ツールとググればいろんなものがヒットします。

WordPressも人気がありますよねー。
確かに高機能で良いツール。
このWordPressをホスティングできるのが、Google Cloudだったりするわけですよ。
そういう意味でも、クラウド基盤に個人サイトを作っておいて、スモールスタートとしておくのは有効な選択肢であろうと思っています。
だからといって「うぉ！ やっぱWordPressなのかぁ！」とか、考えないようにね？

必要なときにリソースやサービスを利用できることを指します。
Google Cloudでは次のような形で柔軟性と効率性を提供し、ユーザーが必要なときに必要なリソースを利用できるように設計されています。

1. オンデマンドトレーニング：
   Google Cloudのトレーニングコースやハンズオンラボを、自分のペースでいつでも受講できる形式です。
   Qwiklabs、Coursera、Pluralsightなどのプラットフォームで提供されています。

2. コンピューティングリソース：
   必要なときに仮想マシンやストレージなどのリソースを動的に割り当て、使用した分だけ料金を支払うモデルです。
   リソースの無駄を減らし、コスト効率を高めることができます。

3. データ分析と機械学習：
   オンデマンドでデータ分析や機械学習のリソースを利用し、ビジネスニーズに応じてスケーリングすることが可能です。

オンデマンドトレーニングについては私もGoogleに限らずいろんな場面でお世話になっていますね。
まともな教科書がないMicrosoft365についてはマイクロソフトが作っている文書で勉強しました。
Googleのプロダクトはとにかくすごい数があるのですよ。
このWebページに紹介しているものの中には、そのプロダクトの中でもデベロッパー向けのものが含まれています。

まず「スケーリング」とは、システムやアプリケーションの負荷に応じてリソースを動的に増減させることです。
パフォーマンスを維持しつつ、コスト効率を高めることができます。
いくつか見ていきましょう。

• 自動スケーリング：
  負荷が増加すると自動的に仮想マシン（VM）を追加し、負荷が減少するとVMを削除する機能。
  常に最適なリソース量を維持できる。

• 予測スケーリング：
  機械学習を用いて将来の負荷を予測し、事前に必要なリソースを準備する方法。
  急な負荷増加にも迅速に対応できる。

• スケジュールに基づくスケーリング：
  特定の時間帯やイベントに合わせてリソースを増減させる方法。
  例えば、毎朝のピーク時間に合わせてリソースを増やすことができる。

これらのスケーリング方法を活用することで、Google Cloudは柔軟で効率的なリソース管理を実現しているのです。
スケーリングがシステムやアプリケーションの負荷に応じてリソースを動的に増減させることですから、「スケーラブル」とは、それができる能力を示します。
表現を変えてみるなら、システムやサービスがユーザーの需要に応じて柔軟にリソースを増減できる能力です。
急なトラフィックの増加やデータ量の増大にも対応でき、システムの安定性とパフォーマンスを維持することが可能となります。
例えば、Google CloudのストレージサービスであるCloud Storageは、データの量が増えても自動的にリソースを拡張し、ユーザーが必要とする容量を提供してくれます。
また、Google CloudのコンピューティングサービスであるCompute Engineも、必要に応じて仮想マシンの数を増減させることができます。

このように、スケーラビリティはGoogle Cloudの重要な特長の一つであり、コンテンツの成長や変化に柔軟に対応できる環境を提供してくれます。
Google Oneの場合、必要に応じて自分で容量を足していかなければ…と、書くところですが。
そんなこと考えずとも、100GBなんてそうそう埋まるようなものではありませんし、ネットワーク負荷でGoogle sitesがどうにかなってしまうことなんて、まずないです。

聞き慣れない言葉かもしれませんが…データベースのスケーラビリティとパフォーマンスを向上させるための技術です。
データを複数の小さな部分、すなわちシャードに分割することで、それぞれを異なるサーバーに分散して保存する方法します。
この方法を使えばデータベースの負荷を分散し、アクセス速度を向上させることができるってことです。

例えばGoogle Cloud Spannerについてお話しします。
このサービスはシャーディングの概念を取り入れており、データベースの書き込み性能を向上させるために利用されています。
また、データベースの話と関連するBigQueryでも自動シャーディング機能を提供しています。
データのスループットを最大化するために動的にシャード数を調整しているんですよね。

シャーディングの主なメリットは、上記にあるように書き込み性能の向上があるでしょう。
データの書き込み先を複数のサーバーに分散することで、書き込み性能をスケールアウトできます。
もちろん読み込み性能の向上も大切です。
読み取りレプリカを作成することで、読み込み性能も向上させることができます。

しかしながら、シャーディングにはデメリットもあるんです。
シャード間でのデータの一貫性を保つために追加でロジックが必要となり、アプリケーションが複雑化していきます。
するとシャードの増設や削除、キャパシティ管理などが複雑になるため、それは結果的に運用管理の煩雑さとなって表面化してしまいます。

余談ですが、SNSでカッコいい話と扱われがちな、システム開発についても少し書いておきますか…
システム開発は次のような流れを辿ることが多いですよね。

システム開発：システム化計画、要件定義
実装フェーズ：設計、開発、テスト
利用フェーズ：運用、廃止

システム開発に関しては 情報処理推進機構「SEC BOOKS：共通フレーム2013」が参考になると思います。
※先日私は情報セキュリティマネジメント試験を受けたけれども…あの試験実施団体である「情報処理推進機構」は、何も試験だけやってるわけではありません。こうやってガイドラインを出したりしている組織です。

要するに、クラウドなら導入決定から利用開始までのスピード、すなわちアジリティの向上が見込めるのです。
システム開発にかかる手間が少ないという。
自分でWebサーバーの設定をしなくて良いからね。
Googleがオープンスタンダードにもとづいた技術を選択することを推奨していることも気に入ってます。
オープンソースソフトウェア（OSS）は私も大好きだし、ベンダーロックインを避けることができます。
ベンダーロックインとは、特定のサービス提供事業者の技術に依存してしまい、他の選択肢を取りづらくなってしまうことです。
例えば、Twitter以外のSNSに移住できない状況とかね？
そんなの…こうやって自分でWebサイトを作って根城にした上で、衛星サイトみたいに各種のSNSを使い倒せば良いだけだと思う。

では、ここから少しだけGoogleと関連したシステム開発のお話をしていきます。

オープンソースとオープン標準は似ていますが、異なる概念です。

オープンソースはソフトウェアのソースコードを公開し、誰でも自由に使用、改良、配布できるようにする開発モデル。
例えば私が大好きなLinuxやMozilla Firefoxが挙げられます。
コミュニティによる共同開発が活発に行われているものは市販ソフトに劣らず高性能であり、透明性と柔軟性に富んでいますね。

一方、オープン標準は誰でも無料でアクセスでき、利用できる技術標準のことです。
例えばTwitterでしょっちゅう話題になっているHTMLや、ネットワークで必ず勉強するTCP/IPなんかもそうです。
これらは標準化団体によって策定され、特許料が徴収されません。

すなわち、オープンソースはソフトウェアの開発と配布に関するもので、オープン標準は技術仕様やプロトコルに関するものです。

リポジトリとは、ソースコードやアーティファクト（成果物）を管理するためのストレージです。
Google Cloudにおける「リポジトリ」には、主に2つのリポジトリサービスがあります。

• Cloud Source Repositories：
  Google Cloudが提供するプライベートGitリポジトリサービスです。
  開発者は、ソースコードを安全に保存し、バージョン管理を行うことができます。
  GitHubやBitbucketと同様に、リモートリポジトリとして機能し、チームでの共同開発をサポートします。

• Artifact Registry：
  こちらは、DockerイメージやMaven、npm、Apt、Yumといったパッケージ管理システムのアーティファクトを格納、管理するためのリポジトリサービスです。
  コンテナイメージやパッケージを一元管理し、デプロイメントパイプラインの効率化を図ることができます。

どちらのリポジトリも、Google Cloudの他のサービスとシームレスに統合できるため、開発からデプロイまでのワークフローをスムーズに進めることができます。

Google Cloudは「Google Cloud コンソール」や「クライアント ライブラリ」を使って普通の操作も可能です。
ただ、私が注目しているのはコマンドライン インターフェースなんですよ。
この「Google Cloud CLI」には、ブラウザベースのシェルである「Cloud Shell」があります。
パソコンに何もインストールする必要はなく、「Google Cloud Console」から開くことができる。
しかもEmacs、Vim、NanoといったLinuxでお馴染みのツールがプレインストールされているんです。
ちなみにGoogle Cloudアカウントを持っていれば無料で使えます。

サイト信頼性エンジニアリングと翻訳されます。
詳しくはサイト信頼性エンジニアリング（SRE）というページにあります。
可用性100%はあり得ないという考え方が根底にある、Googleが提唱している手法です。
可用性100%なんていう目標を立ててはいけない。
そんな実現不可能な目標を目指していては、いろんな資源が無駄になるということです。

およそ「システム」というもののライフサイクルの中で、最も重要なのは運用の部分です。
運用している期間がもっとも長いのは言うまでもありませんが、開発の段階で運用設計を綿密に行う必要があるのです。
まとめて大切な言葉を紹介していきましょう。

提供するサービスの正常性や、パフォーマンスを測定する指標です。
「可用性SLI」は正常なレスポンスの割合、「レイテンシSLI」は期待どおりのレイテンシの割合となります。

そのSLIに対する目標となっているのが、SLO（Service Level Objective）です。
加えて、SLIに対する目標値かつ保証について述べたものがSLA（Service Level Agreement）となります。
SLAの代表的な数値としては、次のようなものがあるでしょう。

• 99.5%＝年間43.8時間停止（おおよそ２日間）

• 99.9%＝年間8.76時間停止（おおよそ９時間）

• 99.99%＝年間52.56分停止（おおよそ１時間）

• 99.999%＝年間5.256分停止（おおよそ５分間）

99.5%でも大したもんだと思いますけどね。
これらの考え方から出発して、エラーバジェットへ進みます。

計算式は「1.0-SLO」です。
例えばこのfein' portalの可用性SLOについて「１か月間の可用性が99.9%」であるとしましょう。
すると、エラーバジェットは「１か月間で0.1%」となります。
この0.1%の範囲内であれば、障害が起きても許容されるというものです。
この考え方はシステムに対する信頼性と、そのシステムの変革という両者のバランスを実現しようとしています。
開発する人はエラーバジェットの使い道を自分で決めて良いとされています。

ちなみに信頼性とは「障害が起きにくい性質」のことであり、可用性とは「システムが稼働し続ける性質」のことです。
似たような意味ですが、ITの話題ではよく耳にする言葉です。

システムを変更してデプロイしていくにあたり、バグは憑き物です。
デプロイに対する考え方としては「段階的な変更」というものがあります。
これはまず一部のユーザーにのみ機能の変更を適用し、様子を見ながら全体に適用するものとなります。

システムを変更してから無事に正常稼働し始めたら、次は現行のシステムが健全な状態であることを示す指標が必要です。
「４つのゴールデンシグナル」という、次のような考え方があります。

• レイテンシ＝リクエストの処理にかかる時間

• トラフィック＝システムに与えられた負荷

• エラー＝エラーの発生率

• サチュレーション＝saturation（飽和度）
  ちょっと聞き慣れない言葉かもしれませんが、これはシステムの全体的なキャパシティーのことです。
  分かりやすく表現すると、どのくらいでCPU利用率が100%になってしまうかという意味です。

Dev(Development)＋Ops(Operations)で作られた造語ですが、これはGoogleが言い出したことではありません。
開発と運用が綿密に連携してリリースの速度を上げようという考え方です。
一方、Googleは「Class SRE implements DevOps」と言っています。
「SREはDevOpsを体現したものだ」という意味となります。
すなわち、次のような姿勢のことを指します。

• 開発チームと運用チームの建設的な協力

• 失敗を責めない

• ビルドとデプロイの自動化

• 開発スピードの向上

素晴らしいですよね。
こういう根本的な考え方も好きで、Googleのクラウドを使っている側面があります。

レイテンシという言葉があります。
よく聞くところの「ネットワーク」をサイクリングロードに例えてみましょう。

• 帯域幅というのは、サイクリングロードの道幅のこと

• レイテンシというのは、自転車の速度のこと

クラウドを使う時、ユーザーと地理的に近いロケーションに配置するのが望ましいです。
地理的に離れていればいるほど、レイテンシは大きくなり、データがある場所から別の場所に到達するまでに時間がかかるようになります。
日本からアメリカまで一本のLANケーブルで接続されているわけではなく、途中でいろんなネットワーク機器がありますからね。
ちなみにDNSというのはドメイン名（google.com）とIPアドレスをマッピングする仕組みです。
マッピングというのは、紐づけるとか、対応づけるといった意味です。
こういった言葉を知っておくと、Twitter等で出回る怪しげなIT裏技から身を守ることができるかもしれません。

ネットワークに接続する際に割り当てられるIPアドレスの一種で、インターネットサービスプロバイダー（ISP）から特定のIPアドレスが固定的に割り当てられるものを指します。
一度設定されると、再接続時にも同じIPアドレスが割り当てられるため、ユーザーが継続的なリモートアクセスを必要とする場合に便利です。

一方、動的IPアドレスは都度異なるIPアドレスが割り当てられるタイプのIPアドレスであり、一時的に利用されます。
動的IPアドレスは、DHCP（Dynamic Host Configuration Protocol）によって自動的に割り当てられ、一定の時間を経過すると更新または返却が必要です。
静的IPアドレスとは異なり、インターネットを切断して再接続してもIPアドレスは変わりません。

静的IPアドレスは特定の用途に向いており、例えばサーバや特定のコンピュータに利用されることが多いです。
一方、動的IPアドレスは一般的な利用環境に適しており、コストが比較的低い反面、障害時には全体の通信が影響を受ける可能性があることを考慮する必要があります。
どちらを選択するかは、利用目的やネットワークの要件に合わせて検討することが大切ですね。

特に難しいことはなく、ユーザーに近い場所に配置されたデータセンターのことです。
データの処理や配信が迅速に行われ、レイテンシ（遅延）が最小限に抑えられます。
データセンターがユーザーに近いため、データの送受信が迅速に行われます。レイテンシ（遅延）が最小限に抑えられるのですが、こういうのは低レイテンシと書かれていることもあります。
これはIoTデバイスやセンサーからの大量のデータを効率的に処理するのにも使われ、Googleの広範なグローバルネットワークを活用してエンドユーザーに高い接続性を提供しています。
つまり、ユーザーはより快適なエクスペリエンスを得ることができるってことだよね。

具体的には、人気のあるコンテンツをエッジノードにキャッシュし、ユーザーに近い場所から提供できる「Google Global Cache (GGC)」や、エッジPOPを利用してコンテンツをエンドユーザーに近い場所にキャッシュして配信する「Cloud CDN」といった仕組みが挙げられるでしょう。

データ処理をクラウドではなく、データが生成される場所やその近くで行う分散コンピューティングの手法です。
低レイテンシ（低遅延）でデータを処理し、ネットワーク負荷を軽減し、セキュリティを強化することができます。
具体的に説明すると、IoTデバイスやその周辺に配置されたエッジサーバーでデータを処理することで、リアルタイム性が求められるアプリケーションに対応します。
例えば、工場のセンサーや自動運転車のデータ処理などが挙げられます。

エッジコンピューティングは、クラウドと連携してデータの一元管理を行いつつ、必要なデータのみをクラウドに送信することで、効率的なデータ処理を実現します。

Google CloudにはCloud CDNというものがあります。
Googleのグローバルエッジネットワークを利用して、ユーザーにできるだけ近い場所からコンテンツを配信するサービスですね。
ウェブサイトや動画の配信速度が向上し、レイテンシが短縮されます。

もう少し詳しく書こうかな…分かりにくいかも。
ウェブサイトやアプリケーションのコンテンツを効率的に配信するための技術なんです。
コンテンツをユーザーに近いサーバにキャッシュしますよね。
するとアクセス速度を向上します。
これによってウェブページの読み込み時間を短縮され、サーバの負荷が軽減されるということです。
数百万人のユーザーに対してもスムーズにコンテンツを配信でき、バックエンドサーバーの負荷を軽減、運用コストも削減されます。
セキュリティとしてもエンドツーエンドの暗号化や、署名付きURLとCookieによるアクセス制御が可能となっています。

Google Cloud StorageやHTTP(S)ロードバランサーと組み合わせて使用することが多いですが、YouTubeやBloggerでも用いられるものです。
Google sitesでは聞いたことないかな？
でもGoogle sitesだけ除外というのも摩訶不思議ですから、おそらく私が知らないだけでしょう。

Google sitesを使った重量級Webサイトの構築は、あまり見かけません。
探せばあるんだろうけどね？
企業サイトで立派なやつはたまに見るけど。
でも日本国内のサイトではほぼ見ないです。
私もGoogle sitesだけを狙い撃ちして検索しまくったわけじゃないから怪しいけどさ。
このfein's portalは、Google sitesで作られているものとしてはそれなりの規模だと思います。

意図せず気付いたらこうなってたんだけどね（笑）
何でもかんでも放り込むから。
アナザーエデンがエンディングを迎えた後、ゲーム以外のコンテンツは徐々にfein's portalからエクソダスしていくことになります。

リージョンはゾーンを含み、ロケーションはゾーンの総称となります。※リージョン⊃ゾーン の関係。
Google Cloudは複数のリージョンとゾーンで構成されていて、これらを総称してロケーションと呼んでいます。

• リージョンの例：アイオワ（us-central1）

• ゾーンの例：us-central1-a、us-central1-b

Google Cloud のロケーション にあるように、日本では東京（asia-northeast1）と大阪（asia-northeast2）にあります。

リージョンとゾーンはそれぞれ異なる役割を持ち、クラウドサービスの可用性や耐障害性を高めるために重要な概念です。
リージョンは、Google Cloudのデータセンターが設置されている地理的なエリアを指します。
例えば、東京や大阪などがリージョンに該当します。
そして、各リージョンは、複数のゾーンで構成されています。

ゾーンは、リージョン内に存在する個々のデータセンターのグループです。
各ゾーンは独立した電源、冷却、ネットワークを持っており、物理的に分散されています。
ゾーンは、リージョン内で高速かつ低遅延な回線で相互接続されています。

ポイントとなるのはまず耐障害性です。
リージョン内のゾーン同士は独立しているため、あるゾーンに障害が発生しても他のゾーンには影響が及びません。
こうすることで、システム全体の耐障害性が向上します。
もう一つは地理的分散です
リージョンは地理的に離れた場所に設置されているため、災害時のリスク分散が可能です。

Googleのネットワークがインターネットと接続する場所のことです。
これらのPoPは、Googleのデータセンターとエッジネットワークを結びつけ、ユーザーに低レイテンシで高パフォーマンスな接続を提供します。
Googleは世界中の160以上の相互接続施設と180以上のインターネットエクスチェンジにPoPを設置しています。
この仕組みがあることで、Googleのトラフィックをインターネットサービスプロバイダー（ISP）やエンドユーザーに近づけることができ、コスト削減や遅延の低減、ユーザー体験の向上が図られているのです。

データベースという言葉、なんかとっても簡単に使われる傾向がありますね。
でもかなり複雑で、奥の深いジャンルだと思っています。
例えばWebサイトに入力→出力の流れを作り、後ろ側でデータベースを動かす。
こういうの、実際にやるとけっこう難しいですよ？

データベースには２つの役割ないしは種類があります。
運用データベース（オペレーショナルデータベース）は、アプリケーションが使うデータベース。
このデータベースに必要な同時多数アクセスや整合性を担保できるデータ処理形式のことを、トランザクション処理と呼びます。
Microsoft SQL Server、Oracle Database、オープンソースではPostgreSQLやMySQLなんかが有名かと。
分析用データベースは、集計や分析のためのデータベース。
運用データベースだと数時間かかる集計処理をすぐに完了できるメリットがあるけど、そんな巨大なデータは個人で扱うことはほぼないのでは？
しかし、最近では蓄積したデータをもとにしてAI・機械学習機能を実行できるものも増えてきたようです。
BigQuery、Azure Synapse、Amazon Redshift、Snowflakeあたりが良く知られているサービスではないでしょうか。
NoSQLなんてものもあります。
これは高いスケーラビリティを持っていて、データの項目や型であるスキーマ定義が柔軟です。
同時多数アクセスが多いWebアプリケーションなどで利用されることが多いですよね。
Google CloudではFirestore、Bigtable。AWSではDynamoDB。オープンソースならMongoDBあたり。

Firestoreはスケーラブルで高性能なNoSQLドキュメントデータベースです。
主にモバイルアプリやウェブアプリのデータの保存・同期・照会に使用され、リアルタイムデータ同期やオフラインサポートも提供しています。

ここで、データベースのデータと言っても次のような種類があることを知っておくと、実際にいろいろやりたくなったときに困らないかもしれません。

• 構造化データ：テーブル

• 半構造化データ：CSV、JSON、XML

• 非構造化データ：画像、音声、動画、PDF、各種のドキュメント

例えば整った構造化データであるテーブルなら、Google CloudのBigQueryを。
いろいろ混じってぐちゃぐちゃの非構造化データなら、Google CloudのCloud Strageを使います。

次に、クラウドでデータベースを扱う場合、次のような流れが考えられるでしょう。

───・───・───
[データの収集]
↓
[データレイク]　例：Cloud Storage
・加工されていない諸々の形式があり、長期保存データ
↓
[データウェアハウス]　例：BigQuery
・加工された構造化データであり、短,中期保存データ
↓
[データの活用]　例：Looker
・分析、可視化、人工知能/機械学習(AI/ML)
・AI/MLは大量のデータから統計的に予測値を算出する技術
───・───・───

データドリブンという言葉があります。
人間の勘や経験に頼るではなく、客観的なデータにもとづいて判断しようという試みです。
上の図は、このデータドリブンなアプローチをするための略図となります。
ちなみにこういったデータの流れをデータパイプラインと呼びます。
規模がどうあれ組織がデータを適切に管理し、セキュリティや品質を維持するためには、適切なデータガバナンスの導入が必要となります。

口で言うのは簡単だけど、データに基づいた客観的な判断なんて…それに至るまでの道筋はけっこう大がかりなものだと思うんですけどね？
それがたとえ趣味の一環であっても、ちゃんとしたものの実現は容易ではないと考えています。

さて、サーバーレス、ないしはフルマネージドなデータパイプラインはインフラの管理が不要です。
Google Cloudでは次のような例があります。

───・───・───
Pub/Sub
例：多数のIoTからデータを受け取る時のバッファとして使われる
↓
Dataflow
例：Pub/Subからデータを取り出し、変換してBigQueryに格納する
───・───・───

このようにしてデータを扱い、いろいろ調べたり表示したりするわけです。
Webサイトで言うなら、そういった結果をレポート形式にして表示させたりできるでしょうね。
ここで、データベースに関連するGoogle Cloudの各種サービスをご紹介します。

Google CloudのPub/SubとDataflowは、データの処理と分析において異なる役割があります。
紛らわしい部分でもあるし、セクションを立てて書いていきます。

Pub/Sub
高いスケーラビリティと信頼性を持つメッセージングサービスです。
データの送信者（パブリッシャー）と受信者（サブスクライバー）を非同期に接続し、リアルタイムでメッセージを配信します。
イベント駆動型のアーキテクチャやリアルタイムデータのストリーミングなどのシーンで使われ、例えばIoTデバイスからのデータ収集や、ログデータのリアルタイム分析などが挙げられるでしょう。

Dataflow
バッチ処理とストリーミング処理の両方に対応した、データの処理と変換を行うためのサービスです。
大量のデータをリアルタイムで処理したり、定期的なバッチ処理を行う際に使われます。
データのクレンジング、変換、集計、そしてデータベースへの格納を自動化が可能です。
Apache Beamを基盤としており、複雑なデータパイプラインを簡単に構築できます。─ Web制作の勉強をした人なら、 Apacheの名称は聞いたことあるのでは？ ─
自動スケーリング機能により、処理負荷に応じてリソースを動的に調整してくれます。

Pub/Subは、メッセージの配信と受信に特化しており、リアルタイムでデータを転送するためのサービス。
Dataflowは、データの処理と変換を行うためのサービスで、バッチ処理とストリーミング処理の両方に対応。
このような違いがあります。

Pub/Subはデータ パイプラインの最初にセンサーなどのデバイス ストリームからデータを受信できるメッセージ サービスであり、Dataflowはデータを受信した後の変換や処理に使用され、データの取り込みには使用されない。
このように書くこともできます。
データ パイプラインの話において、Pub/Sub → Dataflowの流れは押さえておくと良いでしょう。

これらはデータの収集、分析、活用を効率的に行うための重要なコンポーネントとなっています。
簡単に見ていきましょうか。

• スマート アナリティクス
  データのリアルタイム分析や予測分析を行うための高度な分析プラットフォーム。
  データから迅速にインサイトを得ることで意思決定をサポートできます。

• ビジネス インテリジェンス（BI）ツール
  単にBIツールと呼ばれることが多いかも？
  データの可視化やレポート作成を行うためのツールです。
  Google Cloudでは、BigQueryやLookerなどのツールを使用して、データを視覚的に分析し、パフォーマンス評価が可能です。

• ストリーミング分析
  リアルタイムでデータを処理・分析する技術です。
  Google CloudのDataflowやPub/Subを使用して、大量のストリーミングデータをリアルタイムで分析し、即時のアクションを可能にします。

これらのツールと技術を組み合わせることで、データドリブンな意思決定を迅速かつ効果的に行うことができるということです。

ETLというのは特にデータベースに深く関連する言葉で、

• Extract（抽出）

• Transform（変換）

• Load（書き出し）

これらの語句の略です。
データを様々なソースから抽出し、変換して、目的のデータベースやデータウェアハウスにロードするプロセスを指します。

＜ETLのステップ＞

1. 抽出（Extract）：データをオンライン、オンプレミス、SaaSなどのソースから取得します。

2. 変換（Transform）：データをクリーニングし、共通のフォーマットに変換します。重複データや不完全なデータを除去することが含まれます。

3. 書き出し（Load）：変換されたデータをターゲットのデータベースやデータウェアハウスに挿入します。

Google CloudのETLサービスとして、次のようなものがあります。

• Cloud Data Fusion：コード不要でETLパイプラインを構築できるサービス。

• Dataflow：ストリーミングデータとバッチデータの両方を処理できるフルマネージドサービス。

• Dataproc：HadoopやSparkを使用したデータ処理を簡単に行えるサービス。

この「コード不要」というのはよく見ますね。
データの統合や分析を効率的に行うことができます。

クラウドネイティブのデータ処理サービスです。
主にApache HadoopやApache Sparkなどのビッグデータツールをクラウド上で簡単にデプロイ、管理、スケールさせるために使用されます。
クラスターの作成、スケーリング、シャットダウンが平均90秒以内で完了するとされます。
このクラスターの使用時間に応じた秒単位の課金が行われ、無駄なコストを削減できる。
また、BigQuery、Cloud Storage、Cloud Bigtableなどの他のGoogle Cloudサービスとシームレスに統合されています。
加えてクラスター管理やインフラストラクチャの設定が自動化されており、管理の手間が少ないのも特徴と言えるでしょう。

ユースケースとしては、大規模なデータセットの分散処理を行うためのバッチ処理。
Spark Streamingを使用したリアルタイムのデータストリーム。
MLlibによる大規模データセットの機械学習モデルのトレーニングといったものが挙げられます。
このように、Dataprocを利用することで、複雑なデータ処理タスクを効率的に実行できるようになります。

Google Cloudのデータ統合サービスです。
データの抽出（Extract）、変換（Transform）、格納（Load）を効率的に行うETL機能を備え、データパイプラインを迅速に構築および管理することができます。
フルマネージドサービスとなっており、Googleがインフラの管理を行うため、ユーザーはインフラ管理の手間を省けます。
GUI操作ですから、データパイプラインの構築にあたりコードを書かずに済みます。
150以上のプラグインが利用可能で、様々なデータソースと統合できる高い拡張性も備えています。

データの収集、保存、分析、活用までの一連のプロセスをデータジャーニーと呼ぶことがあります。
このプロセスは、データがどのように生成され、移動し、変換され、最終的に価値を生み出すかを包括的に捉えたものです。

1. データの収集：データソースからのデータの収集。

2. データの保存：データウェアハウスやデータレイクにデータを保存。

3. データの処理と変換：データのクレンジング、変換、統合。

4. データの分析：ビジネスインテリジェンスツールや機械学習モデルを使用してデータを分析。

5. データの活用：分析結果を基に意思決定やアクションを実行。

このようにしていけば、データからインサイトを得て、物事の改善や新しい価値の創出に役立てることができる可能性がありますね？

Cloud SQL
リレーショナルデータベースをホストするマネージドサービス（インフラ管理不要）。
オンプレミスでMicrosoft SQL Serverを運用しているようなケースでは、これを用いてデータベースを移行できる。

Cloud Spanner
リレーショナルデータベースをホストするマネージドサービス（インフラ管理不要）。
ゲームなど負荷の高いトランザクション処理が想定され、ユーザーが世界中にいるようなケースでは、これを用いてデータベースを移行できる。
地理的に離れた複数の場所から整合性のある読み書きができる。

Cloud Storage
データレイクに用いられ、長期保存に適している。
次のようなプランがある。

Spannerについては特別セクションにしようかな？
アナザーエデンやヘブンバーンズレッドのようなライブサービスゲームの場合、もちろんデータベースは使われます。
これらのゲームはトランザクション処理が激しく、ユーザーが世界各国にいるわけです。
以下にあるようなサイトはとても興味深いです。

• 実質的に無制限のスケーリングを備えた、常時稼働のデータベース

• ゲームデータベースとしてSpannerを使用する場合のベスト プラクティス

• 株式会社WFS：スマートフォン向けゲームタイトルの開発に Cloud Spanner を採用し、無停止でスケール可能なゲームシステムを構築

BigQuery
データウェアハウスであり、高性能な分析用データベース。
フルマネージドでサーバーレス、かつスケーラブルなデータ分析サービス

Looker
BigQueryからデータを抽出して整形。レポートを作成する高度なBIツール。
Looker Studioは無償のBIツールとなっており、スプレッドシートなどからデータを取得し、分析、可視化できる。

───【注意】──────

このセクションに書いてあることは、私が個人的に学習した内容です。
このようなセクションを書いているにしても、私が下記のようなスタンスを持っているわけではないことを、明確に記述しておきます。

1. 私がAI（特に生成AI）を支持もしくは支持していないこと

2. 私がAI（特に生成AI）を支持もしくは支持していない人々の味方、ないしは敵であること

3. 私がAI（特に生成AI）に対して、中立的な立場にあること

4. 私がAI（特に生成AI）に関係する人々に対して、中立的な立場にあること

5. 私がAI（特に生成AI）に係る各種コンテクストに対して、中立的な立場にあること

すなわち、自身の立場を一切、明言しないこととします。

唯一、私から明確なスタンスを書けるとすれば、次のようになります。
「SNSを用いてAIに関する会話をすることは極めてリスクが高く、建設的な対話の成立は有り得ない。」
とね。

Googleがcode red（Copilotがもたらした非常事態宣言）を発したことは記憶に新しいですが、それに関する過去のページは全て削除しました。
情報が古すぎるし、あのページは十分役割を果たしたからね。
同じAIについて書くなら、Google CloudかMicrosoft Azureの方向から書いたほうが有益でしょう。

──────────────

では、書き始めます🎵

人工知能と機械学習はAI/MLと総称されますが、AIは人の認知能力が必要な作業を代替することが可能です。
Google Cloudで利用できるAIは、基本的に特化型人工知能です。
汎用人工知能ではないんだよね。

教師あり学習では、事前にラベル付けされたデータセットを使用してモデルをトレーニングします。
一方、教師なし学習では、ラベル付けされていないデータセットを使って学習します。
後者はイメージしにくいですが、例えば「大量の魚に関するデータを、魚の習性ごとに分類する」といったものが挙げられるでしょう。
教師データには量と質が必要であり、大量の学習用データを用意して学習を行うことで機械学習モデルが作成されます。
作られた機械学習モデルは入力データに基づいて推論を行い、出力データを返すという流れになります。

CPU(Central Processing Unit)というのはよく聞きますよね。
普通のアプリを動かす、いろんなパソコン等に一般的に付いているものです。
GPU(Graphics Processing Unit)というのは、本来は画像や動画の処理を目的とした集積回路です。
とはいえ機械学習や推論にも使われています。
TPU(Tensor Processing Unit)はちょっと特殊で、これはGoogleが独自開発した集積回路です。
Googleは機械学習開発ライブラリであるTensorFlowを開発しています。
このディープラーニングと呼ばれる機械学習手法において、高い処理性能を発揮できるようになっています。
無理に購入せずとも、Google Cloudを使えばCloud TPUというサービスで利用することができます。

AIは人間の知能を模倣するシステムを作成するための広範な概念と言えるかと。
これには、ロボティクス、自然言語処理、コンピュータビジョンなど、さまざまな分野が含まれています。
AIの目的は、人間の知能をシミュレートできるシステムを作成することです。
MLはAIの一部であり、データから学習するアルゴリズムの開発に焦点を当てている概念です。
MLはデータを使用してパターンを認識し、予測や分類を行うモデルを作成します。
Google Cloudでは、MLを使用して予測分析やデータ駆動型の意思決定を行うことができます。
次に、具体的にGoogle Cloudでどのように扱うのか、利用例を見てみます。

Google CloudのAIサービスには、自然言語処理や画像認識などの高度な機能が含まれています。
自宅にハイスペックパソコンがなくても、チャットボットや画像分類システムなどを構築できるということです。
一方、Cloud ML Engineなど、Google CloudのMLサービスを使用すると、開発者が機械学習モデルをトレーニングし、予測を行うことができます。

つまり、AIは広範な概念なのです。
MLはその中の一部として、具体的なデータ学習に特化しています。
どちらもGoogle Cloudでツールとして利用可能となっています。

Google Cloudのプロダクト列挙を含めて、まとめて書いてみましょう。
下記にある１２３４５の順に、利用する時の難易度とカスタマイズ性が低いです。
逆に５４３２１の順で、要求スキルレベルとカスタマイズ性が高いということになります。

１．AIソリューション
特定の業務に即座に適用できるパッケージ化されたソリューション

• Recommendations AI：商品のレコメンデーションに特化

• Document AI：多様な形式のファイルから文字情報を識別して抽出、分類

• Contact Center AI：コールセンター業務に特化

２．事前学習済みAPI
Googleが開発した学習済みモデルをAPI経由で利用できるサービス

• Cloud Vision API：入力済みの画像ファイルからテキストやイメージを検出する。OCR機能も備えている。

• Cloud Translation API：翻訳機能が充実

• Speech-to-Text API：音声データをテキストデータに変換

• Text-to-Speech API：テキストデータを音声データに変換

• Cloud Natural Language API：テキストの感情分析やコンテンツ分類や語句の抽出など

３．AutoML
プログラミングの知識なしで独自のモデルを構築できるが、大量の教師データを用意する必要がある。

４．BigQueryML
SQLに慣れており、構造化された学習データが既にBigQueryにある場合に使う。

５．Vertex AI：カスタムトレーニング
モデルのトレーニング、デプロイ、モニタリングなどを単一のプラットフォームで行えるものの、スキルが要求される。

…と、その前に。
ここを書く前に今一度、書いておかなければね。

生成AIは現在、著作権に関する問題を抱えています。
それは私個人としても十分に認識していて、であればこそ「SNSで生成AIに吐かせたキメラ・コンテンツを見せびらかす」のは望ましい行為ではない。
と申し上げているわけです。
もっとも、あれらはコンテンツですらないけどね。
ただし、多少なりともITに関するアレコレを把握している者として書くのであれば、「SNSで生成AIに吐かせたキメラ・コンテンツを見せびらかすような（類する行為も含めて）」ことをせず、例えば日々の業務の中で明らかに人がやる必要のない雑用をAIにやらせるであるとか、そういう形であれば現在の状況でも有用でしょう。

こちらのほうがよほど注目に値すると思いますけどね。
SNSで著作権に問題を抱えるキメラ・コンテンツを撒き散らすより、クラウドと組み合わせた自動化の仕組みを構築するほうに私は興味があります。
だって、前者は本人に何も残さないでしょう？
メリットがないということになる。
ゆえに、時間の無駄です。

───────────

では、話を戻します。
Googleの「AIの原則」は、AI技術の開発と使用において責任を持つためのガイドラインです。
これら7つの原則は、GoogleがAI技術を開発する際の具体的な基準として機能し、研究や製品開発、ビジネスの意思決定に影響を与えるとされています。

1. 社会的に有益であること：AI技術は、医療、安全、エネルギー、交通など多くの分野で社会に大きな影響を与える可能性がある。

2. 不公平なバイアスを避けること：AIアルゴリズムやデータセットが不公平なバイアスを反映、強化、または軽減する可能性があるため、特に敏感な特性に関連する不公平な影響を避けるよう努める。

3. 安全性を確保すること：AIシステムが意図しない結果を避けるために、強力な安全性とセキュリティの実践を適用する。

4. 人々に対して説明責任を持つこと：AIシステムは適切なフィードバック、説明、異議申し立ての機会を提供するよう設計される。

5. プライバシー設計原則を組み込むこと：プライバシー保護のための設計原則をAI技術の開発と仕様に組み込む。

6. 科学的卓越性を維持すること：科学的方法とオープンな探求、知的厳密性、誠実さ、協力を重視する。

7. 責任ある使用を促進すること：AI技術の使用が社会に与える影響を考慮し、責任を持って使用する。

関連する話題としては、次のようなものがあります。

＜問題と AI ガバナンスに関する視点＞

1. AI原則の策定：
   2018年にGoogleはAI原則を発表し、これに基づいてAI技術の開発と使用をガイドしている。
   この原則には、上記のように公平性やプライバシー、安全性、透明性などが含まれる。

2. 倫理的レビュー：
   新しいAIシステムの開発において、倫理的なレビューを実施し、バイアスの回避やプライバシー保護を組み込むよう努めています。

3. 多様な視点の取り入れ：
   NGO、業界パートナー、学者、倫理学者などと協力し、AI技術の開発と使用における多様な視点を取り入れています。

＜誰もが利用できる責任ある AI を構築＞

1. Responsible AI Toolkit：
   開発者が責任あるAIを追求するためのツールキットを提供し、AIシステムの公平性や安全性を確保するためのガイドラインを提供しています。

2. AI Opportunity Fund：
   Google.orgは、AI技術を利用して社会的課題を解決するためのプロジェクトに資金を提供しています。

3. 教育とトレーニング：
   AI技術の理解と利用を促進するために、教育プログラムやトレーニングを提供しています。

これらの取り組みを通じて、GoogleはAI技術が社会にとって有益であり、かつ責任を持って使用されることを目指しています。

自社のGoogle Cloudがどのくらいの二酸化炭素を排出しているかのレポートを閲覧できるツールです。
また、Carbon free energy for Google Cloud regionsというサイトもあります。

SDGsなんて言うと話が大きいですが、コスト意識を持ってクラウドツールを使いこなせば、地球環境にも貢献できるのかもしれませんね？
少なくとも、自宅で変にでっかいデスクトップパソコンを組んで一日中電源を入れっぱなしにしておくより、コスト面でも環境面でも優しいでしょう😆ww

Google Cloud は、2030年までにすべてのデータセンターを24時間365日カーボンフリーエネルギーで運営することを目指しているようですね。
すでにデンマーク、フィンランド、アイオワ、オクラホマ、オレゴンの 5 つのデータセンターが90%以上のカーボンフリー電力で稼働しています。

関連サイト：👉 最新データで見るクラウドのカーボンフリー達成度

加えて、Google CloudデータセンターはISO認証も受けています。
Environmental Report 2017 progress update  によれば、資源効率の向上と無駄の削減を通じて、環境パフォーマンスを高めるためのフレームワークを定めたISO14001認証、エネルギー管理のためのISO50001認証、
これらをそれぞれ10か所以上のデータセンターで取得しているようです。

関連サイト：👉 Google 環境報告書 2017

ITインフラストラクチャというのは、アプリケーション（ソフトウェアと同義）が動作する基盤のことです。
パソコンやネットワークのことですね。
2010年くらいかな？
そのくらいまではオンプレミスで保有されることが多かったものの、それ以降は急速にクラウド化が進みました。
身近な話をするなら、今までは自宅のWebサーバーに個人サイトをホストして、そこから派生するソフトウェアをデプロイしていたけど、2010年代以降はクラウドで賄うようになったということです。
ここで、ホストするとは、アプリケーションを搭載して稼働させるという意味で、サーバー上にアプリケーションを配置して稼働可能な状態にすることをデプロイすると言います。

レガシーなシステムというのは、オンプレミスであり、これからこのセクションで記述するような各種の技術を活かされていないシステムです。─ これは「良い悪い」というSNSでよく見られる文脈の中にあるものではないことに、注意してください。─
モノリシックアーキテクチャだと障害発生時に大事になるし、マイクロサービスアーキテクチャのように柔軟な運用が難しい。
マイクロサービスアーキテクチャの例はいろいろありますが、Amazon、Netfix、Uber、LINEなどがあります。
具体的に言うと、商品の検索と購入、定期的な商品購入の管理や商品そのものの管理といったいろんな機能を１つのシステムにしているのがモノリシックアーキテクチャです。
それを独立した別々のシステムに分割しているのがマイクロサービスアーキテクチャです。

複数のサービスやコンポーネントがあり、それの構成、調整、管理が自動化されているとき、オーケストレーションが行われていると認識できます。
複雑なプロセスやワークフローを効率的に実行できるようになりますね。

• Workflows：サーバーレスのワークフローオーケストレーションサービスで、複数のGoogle CloudサービスやHTTPベースのAPIサービスを統合し、自動化できます。

• Cloud Composer：Apache Airflowを基盤とした完全管理型のワークフローオーケストレーションサービスで、データパイプラインの定義、スケジュール、監視を行います。

• Cloud Scheduler：定期的な単一サービスの実行をスケジュールするためのサービスです。

Google Cloudのオーケストレーションについて、具体的に考えてみるとこういう感じになるでしょうか。
でもオーケストレーションというのはある種の状態を指す言葉であって、必ずしも特定の機能に依存した話ではないんです。

私のアカウントである「fein.den_scoth_mn」で例えるなら、今まではTwitter上の単一アカウントに過ぎませんでした。
これは表示機能や会話機能、画像やデータのストレージのような役割まで一つのアプリでこなしていた。
しかし、このようにプロプライエタリなソフトウェアであるTwitterに依存していたことで、Eロンによる粗暴な運営の被害をまともにくらったわけです。
プロプライエタリ（Proprietary）なソフトウェアとは特定の企業や組織が権利を保有していることですが、そこからの移行先として有力な候補の一つだったのがGoogle sitesだったのですよ。
それだってGoogleに依存しているじゃないかと言われるかもしれませんが、それはこれからの記述をお読みいただければ意図が分かります。

fein's portalは、見た目は単なる個人サイトです。
建前としてもそれが適切ですからね？ ─ IT的な話を挟めば、まず第一に、クラウドはスモールスタートが推奨されているのです。─
しかし、これは単なる「表示機能」に過ぎません。
会話機能は従来通りテキストベースでTwitterで行い、画像表示に関してはInstagramで行う。
ストレージ機能はGoogle sitesのバックにあるDriveで行います。補足手段としてMicrosoftのクラウドも使う。
このようにして、今まで全てをTwitterに委ねていたものを、各種の機能に分割したんだよね。
大袈裟な表現をすると、マイクロサービスアーキテクチャへ移行するという「考え方を」、目指したのです。

これらfein's portalの例え話は、SNSで言うところの「おふざけ」に過ぎません。
おっと…
あまり「おふざけ」が過ぎると、こっぴどく恥をかいてしまうかも😆ww
このへんにしておきましょうか♪
おふざけでは済まされないレベルの悔恨を残すかもしれない🤣ww

マジなGoogle Cloudで話すとするなら、クラウドやコンテナという技術によってインフラの準備やスケーリングが容易になった側面が強いのです。
マイクロサービスアーキテクチャが作りやすくなった。
利用が多いサービスだけ個別にスケールすることでスケーラビリティが向上し、障害が全体に波及しないような可用性が達成されます。
同時に改修の影響範囲を狭めることで、保守性を向上させる。
各種の機能が分割されていればこそ、このようなことがやりやすい。
プロプライエタリなソフトウェアに依存していては何かあった時に大変ですから、できるだけオープンソースを用いるようにする。
セキュリティも大切です。
昔のような境界型セキュリティでは、複数人によるアプリの編集の際にリスクが考えられます。
Google Cloudはゼロトラストセキュリティの考え方があるため、全ての人とデバイスが逐一チェックされるようにもできます。

ITインフラストラクチャはGoogle Cloudにとっては極めて重要な部分です。
そこに行く前に、ちょっとだけネットワークの話をしておきます。
基盤となる部分ですからね。
イメージがわかないと、思わぬところで転ぶかも？

共有VPCとVPCネットワーク ピアリングはGoogle Cloudでのネットワーク管理において重要な機能ですが、それぞれ異なる目的と使い方があります。
「共有 VPC」は、組織内の複数のプロジェクトが一貫したネットワーク管理とセキュリティポリシーの下でリソースを共有するため。
「VPC ネットワーク ピアリング」は、異なる VPC ネットワーク間でプライベート接続を確立し、リソース間の通信を可能にするためのものです。

Google Cloudにある、フルマネージドのインメモリデータストアサービスです。
さっと見る限りだと、RedisとMemcachedという2つのオープンソースのキャッシングソリューションを提供しているようですね。

高速性とスケーラビリティ、99.9%の可用性保証、VPCネットワークとプライベートIPによるセキュリティ、その他プロビジョニングやパッチ適用も含めて複雑なタスクを自動化します。
用途としては、ウェブコンテンツやセッションストアのキャッシュを保存したりとか。
DataflowやPub/Subと組み合わせたストリーミング処理に使われたりします。

あと、ゲーム内でプレイヤーのスコアをランキング形式で表示する機能なんかもそうですよね。プレイヤーのスコアを記録して順位を決めていく。
あれについてはSorted Set型データ構造といって、データを自動的に順番に並べて保存する仕組みが背景にあったりしますよ。

このように、Memorystoreはリアルタイムのデータ処理が必要なアプリケーションに適していると考えて良いと思います。

仮想マシン（VM）を管理するためのソフトウェアです。
物理的なハードウェア上で複数の仮想マシンを同時に実行できるようにする役割を果たします。
Google Cloudでは、オープンソースのKVM（Kernel-based Virtual Machine）ハイパーバイザを使用しています。

ハイパーバイザには主に2種類あります。
「タイプ1（ベアメタル）ハイパーバイザ」は直接ハードウェア上で動作し、物理マシンのリソースを仮想マシンに割り当てます。
Microsoft Hyper-Vがこのタイプ。
使ったこともあるけど、VirtualBoxのほうが扱いやすいと感じたかな。
「タイプ2（ホスト型）ハイパーバイザ」は既存のオペレーティングシステム上で動作し、その上で仮想マシンを実行します。
こちらはVirtualBoxなんかが事例となります。
VirtualBoxはよく使ってましたね。
主にLinux上でWindowsを開くのに使ってました。

ちなみにGoogle CloudのKVMハイパーバイザは、タイプ1に分類され、Google Compute EngineやGoogle Kubernetes Engineの基盤として使用されています。

仮想サーバー（仮想マシン）を用いたリフト＆シフトは、個人レベルではあまり馴染みがないでしょう。
普通はクラウドへ移行する時、２段階に渡ってやることが多いのです。
たとえ個人レベルであっても、自宅のPC環境を丸ごとクラウドに移すのは骨が折れます。
私は学生時代にやったのですが、けっこうな手間がかかりました。
そのおかけでスムーズなfein's portalへの移行があったんだけどね。
話を戻すと、まずはオンプレミスのアプリケーションや環境を、同じようなインフラアーキテクチャでとりあえず仮想サーバーへ移行します。
それからクラウドを活かしたインフラアーキテクチャに移行していき、運用も検討する。

コンテナはミニサーバーと考えれば良いかもしれません。
アプリが動作するには、OS・ミドルウェア・アプリケーションなどの一連の環境が必要です。
それらの情報をコンテナイメージというファイルにパッケージ化するのですよ。
Google Cloudの文脈で語るとすれば、Compute Engineでアプリケーションをホストしているとしましょう。
ここで言うアプリというのは、fein's portalが多機能化した未来のWebアプリ版fein's portalなどと想像して頂ければ。
しかし、そのfein's portalをもっと良くしようとして開発及び機能追加をしまくった結果、アプリケーションは複雑化してしまいました。
これがどういう結果を招くかというと、スケールアウトするタイミングでVM起動が遅くなってきたりします。─ スケールアウトという概念は大切です。分からなければ上述の記載に戻りましょう。VM起動は後述します。─
こういうときにコンテナへの移行が検討されるってわけです。

PaaSはサーバーレスのクラウドと言えます。
サーバーレスにすると、初期開発・運用・月額コストが低く、それでいてスケーラビリティの高いシステムを構築できます。
でもしっかりデメリットもあるんです。
仮想サーバーに比べてカスタマイズ性に劣り、大きなリソースが必要なアプリケーションには不向きでしょうね。
個人レベルに落とし込むなら、fein's portalはGoogle sitesでコンテンツ表示してるだけですから、カスタマイズ性に大きく見劣りします。
デフォルト状態では簡単な表さえ作れない。
でも仮想サーバーにWebサイトを構築すれば、何だってやれちゃうわけです。
その分だけ手間がかかるんだけどね。

この「手間」とか「規模」とかいうのはとっても大切です。
いくらEロン率いるTwitterから逃走すると言っても、Compute Engineでfeinアプリケーションをホストしてなんてやってたら、仮想サーバーの構築から始めないといけない。
そんなことをやっている暇はなかったわけです。
スピード感をもって規模の小さめなプログラムを動かす際は、このサーバーレスが第１の選択肢になると言って良いでしょう。
方向性を変えてビジネスの話をすると、新しく始めたインターネット商店があるとします。
開店当初はユーザー数の予想が付かないでしょうから、そういうときにサーバーレスにしておけば、無駄なコストもかかりません。

いっぱい書きましたが、モダナイゼーション（近代化）って重要なんですよ。
手間を省いてリリースサイクルの高速化を図っていくことも大切です。
個人サイトを作りたい＝どのサービスを選べば良いか。─ SNS的な文脈をお借りするなら、どのサービスなら他ユーザーにマウントを取れそうかといった不毛なコンテクスト。 ─
そんなことをやっていては、いつまでも「レガシーなアカウント」のままです。
私が考えていたのは、そういうことですよ。

ではここから、モダナイゼーションに貢献するGoogle Cloudのサービスを少し詳しく書いていきます。

これらのサービスについて、お話していきます。

• Compute Engine：仮想サーバー

• Google Kubernetes Engine：サーバー上で動作させるコンテナ

＜サーバーレスと関連が深い＞

• Cloud Run：コンテナをデプロイ、Webアプリケーションやバッチ処理向け

• Cloud Functions：ソースコードをデプロイ、イベントドリブンで短時間の処理向け

• App Engine：デプロイ戦略の柔軟性確保

＜他サポート＞

• GKE Enterprise：マルチ＆ハイブリッドクラウドができるコンテナ

• Google Cloud VMware Engine：VMware仮想サーバーを使っていた組織向け

LinuxやWindows Serverなど、仮想サーバーOSを利用できます。
この時点で凄いと思いますよ？
サーバーをブラウザ越しに借りることができる。
もちろんOSレベルの設定が可能でカスタマイズ性も高いです。
オンプレミスの環境をほぼそのまま移行することができてしまいます。

Compute Engineで構築された仮想サーバーのことを、VMあるいはインスタンスと呼びます。
Compute Engine VM・Compute Engine インスタンスなどと書かれたりする。
これはGoogle Cloudサービスの一環ですから、オートスケーリングも可能です。
Google Cloudという範囲内に仮想ネットワークとしてVirtual Private Cloudがあり、その中に必要な分だけCompute Engine VMを構築できるイメージです。

おそらく使う可能性は低いと思われるけど、プリエンプティブルVM（仮想マシン）なんてものもありますよ。
通常のVMよりも大幅に割安な価格で利用できる仮想マシンです。
ただし、24時間以内に停止される可能性があり、長時間の稼働や高可用性が必要な用途には向いていません。
主にバッチ処理や一時的なタスクに適しています。
何かテストしたいなら、目立たないところに専用ページ作っちゃうしね。

コンテナアプリケーションをホストするためのプロダクトです。
スケーラビリティを得るためにアプリケーションをコンテナ上で動作させることは、既に記述しました。
アプリケーションのリリースサイクルを高速化できるでしょう。

ソースコードをアップロードするだけでプログラムが動作します。
私が以前に見てみた範囲では、PHPやNode.jsなども利用可能でしたね。他にも使えるはず。
インフラ、OS、ランタイムの管理が不要なので、運用コストが非常に低いことに注目。しかし制約も多いです。
簡素で実行時間が短い小規模プログラム向けであり、例えばイベントドリブンなプログラムの稼働に適しているでしょう。

ランタイムというのは、プログラムが動作する基盤となるソフトウェアのことです。
あんまり聞かない印象あるけどね。

一方、イベントドリブンとは、システム的なイベントをきっかけにして処理が起動することです。
SNS的に語るなら、フラグとか呼ばれているものかな？
あれってネットスラングだと思うけど、こういう事象を指しているのでしょう？

Webアプリケーションやバッチ処理など、シンプルなアプリケーションに向いています。
Google Kubernetes Engineと似ていますが、こちらはサーバーレスですから、管理の手間が少ないのがメリットでしょう。

ソースコードをアップロードするだけでプログラムが動作します。
プラン選択によってはCloud FunctionsやCloud Runのような制約はないものの、費用はかかりますよね。
今後、ご縁があるといいけどねー。

カナリアデプロイなどに適しています。
カナリアデプロイというのは、僅かなユーザーにのみ新機能を公開し、問題ないかを確認しながら徐々に公開範囲を広げる戦略です。
カナリアリリースとも言います。

Google Kubernetes Engineの仕組みを使い、単一の管理や運用の体制で、クラウドとオンプレミスの両方に同じアプリケーションを展開できます。

私が強く興味を持っている体系の一つです。
GKE Enterpriseを使うことでマルチクラウドにできる。
いろんな機能を分散させたほうが良いと思うから、Google Kubernetes Engineの体系を他クラウドに拡張する選択肢があるということを覚えておきたいと考えてます。

VMwareを使っているところは多いですよね。
でも肝心の会社が買収された。
それの移行先として有力なサービスです。
VMwareから基盤技術が異なるCompute Engineへ移行しようとすれば手間がかかります。
それをスムーズにGoogle Cloudに移行できるということです。

私もVMwareを使ったことはあるけど、なんかイマイチでしたね。
当時は学生で理解不足であったことも大きいですが、まぁこういうサービスもあるんだなと覚えておいてます。

Google Cloudの「Anthos」は、ハイブリッドおよびマルチクラウド環境でのアプリケーション管理を簡素化するためのプラットフォームです。
オンプレミス、Google Cloud、他のパブリッククラウド（例えばAWSやAzure）を含む複数の環境でアプリケーションを一貫して管理できます。
Google Kubernetes Engine（GKE）を中心に構築されており、コンテナ化されたアプリケーションのデプロイメント、管理、最適化を可能にしていますね。
同時にAnthos Service Meshを使用して、マイクロサービス間の通信を管理し、セキュリティや可観測性を向上させる。
また、Anthos Config Managementを利用して、ポリシーや設定を一元管理し、コンプライアンスを維持する。

個人でハイブリッドクラウドというのはあまり意味がないだろうけど、マルチクラウド環境ならいくらでも事例があるでしょう。
私が実際にそうだからね。
Anthosを利用することで、既存のインフラストラクチャを活用しつつ、クラウドネイティブなアプリケーションの開発と運用を効率化できます。

Migrate to Virtual Machines（Migrate for Compute Engineとも呼ばれます）は、オンプレミスや他のクラウド環境からGoogle Cloudの仮想マシン（VM）にワークロードを移行するためのツールです。
VMware、AWS、Azureなどの環境からGoogle CloudのCompute EngineにVMを移行することができます。
つまり、既存のインフラストラクチャを効率的にGoogle Cloudに移行できるということです。
VMのディスクをGoogle CloudのPersistent Diskに移行することもできて、Google Cloudコンソールで移行先のグループを作成するだけです。

一方、Migrate to Containersは従来の仮想マシン（VM）ベースのワークロードをコンテナに変換し、Google Kubernetes Engine（GKE）やCloud Runで実行できるようにするツールです。
このツールを使うことで、既存のアプリケーションを効率的にモダナイズし、クラウドネイティブな環境での運用が可能になります。
VMwareやCompute Engine上で動作するワークロードをコンテナに変換するのですが、IBM WebSphere、JBoss、Apache、Tomcat、WordPress、Windows IISなどのアプリケーションをサポートしています。
インターネット接続がなくてもローカルネットワークで移行作業を行うことができるのも良いですね。
CLIツールまであって、軽量なコマンドラインツールでローカルマシンでワークロードを移行できます。

WordPressもコンテナ化できるのは便利かと思いますね。
こういうところを見ると、fein's portalからエクソダスさせるページ群はとりあえずWordPressを使うという選択肢も十分に有効と考えられます。

「Persistent Disk」は、Compute Engineの仮想マシン（VM）インスタンスに対して信頼性が高く高性能なブロックストレージを提供するサービスです。
デスクトップやサーバーの物理ディスクのようにVMからアクセスできる耐久性のあるネットワークストレージデバイスとなっており、VMのブートディスクとして使用することも、追加のデータディスクとして使用することも可能です。
他のGoogle Cloudサービス同様、耐久性とスケーラビリティを備えています。
また、このPersistent DiskはVMから独立して存在するため、インスタンスを削除してもデータを保持することができます。

Virtual Private Cloud（VPC）についても書いておこうかな。
VPCというのは仮想的なネットワークのことです。
Google Cloudという大きな枠があり、その中にVPCというネットワークがあります。
そして、その中でCompute Engine VMが稼働するわけです。

これまたTwitterでよく拡散されてますね。
APIネタね。
インターネットを経由したWeb APIによるデータ連携が一般的です。
あるプログラムがあるとして、そこへ別のプログラムから命令を受けるための入口のことですよ。
例え話が良いと思うけど、「あるソシャゲアカウントが過去1年間に行った投稿からファボリツ数を集計する」なんて作業が挙げられますよね。
手作業せずともXにはAPIがあるため、それを呼び出しつつプログラム集計できるのです。
アプリケーションにAPIを構築すると、プログラム同士が相互通信することで、バッジ処理などに比べてリアルタイムな情報取得が期待できます。

と…こう書くと「feinはXのAPIで何かしようとしているの？」となるのかしら😆w
んー…今さらXのAPIなんか把握してもね…

Eロンが広告主とさえ喧嘩するから、ビジネスユースとしてもどうなのと感じますよ。
もう、衰退していく一方でしょう。
テキストベースの会話アプリとしてだけ残ってくれれば、上出来と言えましょう。
同じAPIを把握するなら、他のWebサービスのほうがメリット大きいと思いますよ？
例えば、Google Cloud APIsとか。

GoogleのサービスごとにAPIが用意されていて、作業の自動化が可能です。
Google Cloud APIsは、Google CloudサービスのAPI群の総称と言えます。

Xよりこっちのほうが断然おもしろいと思いますね。
例えば、Google sitesには「Drive API」というものがあり、サイトへの自動アクセス、ファイル単位の操作などが可能となっています。
私もいずれはAPI使ってfein's portalに何か表示したり、いろいろするかもしれないよ？

ここで重要なのが「自動化するための手間」と「従来通り手作業でやる手間」の比較です。

アプリケーションにAPIを実装するためのフルマネージドプラットフォームです。
外部のシステムと自社アプリケーションの間に設置され、API連携するためのGoogle Cloudサービスとなります。
これのメリットは外部システムから直接アクセスさせないようにできるので、セキュリティが向上して監視もやりやすいですよね。

Google Cloudにおける「フルマネージド」とは、インフラ管理の自動化・スケーリングの簡便さ・高可用性と障害復旧・コスト効率が挙げられます。
ユーザーがインフラストラクチャの管理やメンテナンスを行う必要がないサービスということです。
だから、私はこうして「書く」だけで良いのですよ。
自分のアカウントが保有するコンテンツの管理及び拡充、並びにEロンからの逃走にはぴったりでしょ？

父によれば、昔はクラウドにデータを預けること自体、安全性に懸念があると言われていたようです。
しかし最近はどうでしょう？
ISMAPクラウドサービスリストなんてものを政府が作っていたりします。

クラウドは、ユーザーがセキュリティ設定を適切に行っている限り、とても安全なものです。
事業者が規格に則った認証を受けていることもありますが、下手な個人パソコンなどより遥かに厳しいセキュリティ対策を実施しているからです。

ここで、基礎的な情報セキュリティについては既に把握している前提で、クラウドのセキュリティについて、お話していきます。
クラウドであろうと情報セキュリティの基礎的な部分は変わりませんけどね。
機密性・完全性・可用性を維持することが重要という。

複数のセキュリティ層を組み合わせて、システム全体の安全性を高める方法です。
このアプローチは、以下のような複数のレイヤで構成されています。

• 物理セキュリティ：
  データセンターの物理的な保護を強化するために、アクセス制御、監視カメラ、バイオメトリクスなどを使用します。

• インフラストラクチャのセキュリティ：
  ネットワーク、サーバー、ストレージなどのインフラストラクチャを保護するために、ファイアウォール、侵入検知システム、暗号化などを導入します。

• アプリケーションセキュリティ：
  アプリケーションレベルでの脆弱性を防ぐために、セキュアなコーディングプラクティスや定期的なセキュリティテストを実施します。

• データセキュリティ：
  データの保護を強化するために、データの暗号化、アクセス制御、データ損失防止（DLP）などの技術を使用します。

• ユーザーセキュリティ：
  ユーザーの認証とアクセス管理を強化するために、多要素認証（MFA）やシングルサインオン（SSO）を導入します。

このように、Google は多層的な防御を実施することで、各レイヤが相互に補完し合い、全体として強固なセキュリティを提供しています。

認証・認可・監査の頭文字を取ってAAAと呼ばれることもあります。
それに付随する要素も含めて、記述しましょう。

• 認証（Auhtentication）
  システム利用者が本人であるかを確認するプロセス

• 認可（Authorization）
  システム利用者にシステム利用権限を付与し、操作の可否を決定するプロセス

• 監査（AuditingもしくはAccounting）
  利用、操作履歴を記録すること。

• アイデンティティ（ID）
  認証の対象となる人間やプログラムのこと。

まずはここらへんかな？
Googleクラウドを使うとき ─ 他のクラウドであっても ─、各種の機能やデータへのアクセスに認証が必要な設定にするべきです。
公開設定にする部分の方が、少ないと思われます。
例えば私の場合、このfein's portalで表示している範囲のみです。
このようにインターネット全体に意図的に情報を公開したい場合を除いて、全て認証を通すのが大切です。

「責任共有モデル」という言葉は、クラウドにおいて重要です。
IaaSやPaaSでは、アプリケーションレベルのセキュリティ対策がユーザーの責任となります。
Google WorkspaceのようなSaaSでは、アプリケーションレベルのセキュリティ対策もクラウド提供事業者の責任となります。

アプリケーションレベルのセキュリティというのは、なかなか馴染みがないかもしれません。
例えばこのfein's portalには「質問できるフォームを開設しました」という自由記述式フォームがありますが、悪意あるユーザーによってフォームへスクリプトを入力される可能性があります。

IaaSやPaaSの場合、そこに対するベストプラクティスとなる設定やセキュアコーディングは、私の責任となるでしょう。
しかしGoogle sitesはSaaSですから、Googleの責任です。

このように、必要もないのに自身へ責任がかかる事態を回避し、プロフェッショナルへお任せできるのも、クラウドのメリットと言えます。
仮に私が情報セキュリティマネジメントを100%完璧にできる人物であったとしても、それには膨大な手間がかかります。
万が一の事故があれば、およそ個人では事態の収拾が難しい状況に陥る可能性を否定できません。

Google Cloudではデータを配置するリージョンを選択できます。
当然のことながら、Googleが勝手にデータにアクセスすることもできません。
これはある国・地域で収集、保管されたデータは、その国・地域の法令に従うものであり、他国によって侵害されるべきではないとする、データ主権という考え方に基づくものです。
AI学習が問題となっている今、この「データ主権」という話題が重要になってくる可能性もありますね。

データに関する権利について話をするとき、どうやら…🤔
「著作権博士であれば良い」というものではないみたいですね？