128
133

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【初心者向け】物理層と論理層がわかったら、クラウドが一気にスッキリした話

128
Posted at

はじめに ― クラウドサービスが多すぎて混乱していた頃

データエンジニアとして働き始めた頃、一番困ったのが 「クラウドサービスが多すぎて、何がなんだかわからない」 ということでした。

EC2、Lambda、S3、EBS、EFS、RDS、Aurora、Redshift、Glue、Athena……。AWSだけでも200以上のサービスがあり、GCPやAzureまで含めるともはやカオスです。

ドキュメントを読んでも「なぜこのサービスが存在するのか」がピンとこない。似たようなサービスの違いが説明できない。そんな状態がしばらく続きました。

しかし、あるとき 「物理層」と「論理層」 という視点を手に入れてから、クラウドの全体像が一気にスッキリ整理できるようになりました。
この記事では、その考え方を私なりにまとめてみました。
私自身がデータエンジニアなので多少データよりの記事になっています。

この記事は初心者向けに概念の大枠を伝えることを目的としています。厳密なインフラ設計では、より詳細な考慮事項がありますのでご了承ください。

そもそも「物理層」と「論理層」ってなに?

日常の例えでイメージをつかむ

まずは身近な例で考えてみましょう。

マンションに例えると:

物理層 論理層
何か? 建物そのもの(鉄骨・コンクリート・土地) 部屋の区画・住所・管理規約
特徴 実際に触れる。動かせない。壊すのは大変 人間が決めたルール。変更しやすい

マンションの建物(物理)は簡単に動かせませんが、部屋の間取り変更や住所の割り当て(論理)はリフォームや届出で変えられます。ITの世界もこれと同じ構造を持っています。

ITにおける物理層と論理層

物理層 論理層
意味 実際のハードウェア・設備 ソフトウェアで抽象化された世界
サーバー機器、HDDやSSD、ネットワークケーブル、データセンターの建物 仮想マシン、コンテナ、仮想ネットワーク、オブジェクトストレージ
変更の手間 大きい(調達・設置に数週間〜数ヶ月) 小さい(APIやコンソールで数分)

クラウドの本質は、「物理層をクラウドベンダーが管理し、ユーザーには論理層を提供する」ことです。どこまで物理を隠すか(=どこまでマネージドにするか)の違いが、サービスの差になります。

クラウドを「物理と論理」で眺めてみる

ここからはAWSを例に、具体的なサービスを物理と論理に分解していきます。

ネットワーク:リージョン/AZとVPC

image.png

  • 物理層:リージョンとアベイラビリティゾーン(AZ) は、実際のデータセンターの「場所」です。東京リージョンなら、物理的に日本国内のどこかにサーバーが置かれています。
  • 論理層:VPCやサブネット は、ソフトウェアで定義された仮想ネットワークです。IPアドレスの範囲やルーティングは自由に設計できます。

サブネットを作るときにAZを選ぶのは、「論理的な区画を物理的な場所に紐づける」作業です。この操作こそが物理と論理の接点になっています。

コンピュート:物理サーバーとその上の世界

image.png

ストレージ:ディスクとオブジェクト

image.png

データエンジニア向け「物理/論理」の視点

ここからは、データエンジニアの日常業務に直結するポイントに絞って解説します。

S3:「ただのファイル置き場」ではない

S3はデータレイクの基盤としてよく使われますが、物理層の知識があるとコスト最適化が進みます。

s3://my-data-lake/
├── raw/          ← 頻繁にアクセス(S3 Standard)
├── processed/    ← たまにアクセス(S3 Standard-IA)
└── archive/      ← ほぼアクセスしない(S3 Glacier)

S3のストレージクラスは、裏側の物理的な保存方法(高速SSD ↔ 低速テープ) の違いを論理的なクラス名で抽象化したものです。データのアクセス頻度に応じてクラスを選ぶことで、大幅なコスト削減が可能になります。

S3ライフサイクルポリシーを設定すれば、「作成から90日後にGlacierへ移動」のように自動で物理層の最適化ができます。データエンジニアとしてぜひ覚えておきたい設定です。

サーバーレス:物理を隠した究極のマネージド

データパイプラインでよく使うサービスを物理の隠蔽度で並べると、次のようになります。
それぞれ役割が異なるので同じ並列で並べるのは厳密ではないですが、
初手の段階ではこの理解で十分なのでは?と思っています。

image.png

データベース:RDS vs. Auroraの違いも物理と論理で整理できる

RDSとAuroraはどちらもマネージドRDBですが、物理と論理の切り分け方 が異なります。

image.png

「RDSとAuroraの違いは?」という面接での定番質問にも、「ストレージの物理と論理の切り分けが違う」と答えれば、本質を突いた回答になります。

「なぜこのサービスが存在するのか」が見えてくる

マネージド度合い=物理層をどこまで隠すか

ここまで読んで気づいた方もいるかもしれませんが、クラウドサービスの違いの多くは 「物理層をどこまで隠すか」 の違いです。

image.png

新しいサービスに出会ったら

新しいクラウドサービスに出会ったときは、次の3つを問いかけてみてください。

  1. このサービスは何の物理リソースを抽象化しているのか?(コンピュート?ストレージ?ネットワーク?)
  2. 物理層をどのくらい隠しているか?(IaaS寄り?SaaS寄り?)
  3. 物理層の制御を手放すことで、何を得ているのか?(運用負荷の軽減?スケーラビリティ?コスト最適化?)

この3つの問いだけで、初見のサービスでもかなり正確にポジションを把握できるようになります。

データパイプラインのボトルネック切り分け

データパイプラインが遅いとき、物理と論理の両面から切り分けると効率的です。

image.png

この表を手元に持っておくだけで、「まず論理層を見て、それでもダメなら物理層を疑う」という体系的なトラブルシューティングができるようになります。

まとめ ― 迷ったら「それは物理?論理?」と問いかけよう

この記事のポイントを整理します。

  • 物理層 = 実際のハードウェア・データセンター。変更が大変で、コストやパフォーマンスに直結する
  • 論理層 = ソフトウェアで抽象化された世界。柔軟に設計・変更でき、クラウドの操作の大部分はここ
  • クラウドサービスの違いは 「物理層をどこまで隠すか」 で整理できる
  • トラブルシューティングでは 論理層だけでなく物理層(リージョン、AZ、ストレージタイプ)も確認する
  • 新しいサービスに出会ったら 「何の物理を、どこまで抽象化しているか?」 を問いかける

「それは物理?論理?」 ── たったこの一言の問いかけが、クラウドの迷子から抜け出すコンパスになります。

この記事が、以前の自分のようにクラウドサービスの洪水に溺れている方の助けになれば幸いです。

128
133
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
128
133

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?