SSD, コラム, 勉強会

おはようございます。ライトノベル好きの新人ツチノコです。オー・ドロボー!は読みましたか?

さて、本題ですが火曜日に開催している部内勉強会でSSD関連の話をしました。
そのうち、SSDの最近のtopicを話した部分をご紹介します。

SSDとは

SSD(Solid State Drive)は、Flashを用いてHDDの代わりに情報を記憶する装置として知られています。
コンピュータっぽい用語を使うと「半導体素子を用いた二次記憶装置」ということになります。

一昔前は大変高価なデバイスで利用方法も限定されていましたが、今ではノートPCからエンタープライズ向けのサーバまで幅広く利用されるようになりました。

HDDと比べると、SSDの利点と欠点は以下のようなものがあります:

  • 利点
    • ランダムアクセス性能がよいこと
    • 物理的な稼働箇所がないので、静音・壊れない
  • 欠点
    • 容量単価が高価
    • Writeしていくと性能が劣化

SSD最近のtopic

SSDはここ数年で大変進歩しており、現在でも次々と新製品・新仕様が出てきています。

  • PCIe-SSD
  • NVM Express
  • M.2(NGFF)
  • SATA Express
  • mSATA
  • などなど

このうちいくつかをピックアップします。

PCIe-SSD

厳密に定義された用語ではありませんが、PCI Express(以下PCIeと表記)で接続されたSSDの総称として、PCIe-SSDという表記を使うことにしてます(少なくとも関係者間で意味が通るので・・・)。

2007年Fusion-io社が最初の製品であるioDriveを発表しました(ご参考: 当時のPress Release(pdf/web archive))。
ioDriveはPCIe Card1枚で100k IOpsという性能でした(ご参考: HDDだと数100IOps, SAS SSDだと数10kIOps)。当時の従来製品であったSAS/SATA SSDと比較して高速でしたし、FC接続されたRAID装置に匹敵する性能を安価に実現できたことから一時代を築くこととなりました。

Fusion-io社のioDriveの成功以降、Virident社・Huawai社など各社がPCIe-SSD製品を出荷しています。
すでにDMM.comのインフラにも大量に投入されており、このブログでも性能評価結果を記事にしています。

NVM Express

NVM Express(以下NVMeと表記)の前に、まずVolatile MemoryとNon-Volatile Memoryの説明をしたいと思います:

  • Volatile Memory:
    電源を切ると内容が消える記憶装置のこと。いわゆるメモリなど。
  • Non-Volatile Memory:
    電源を切っても内容が消えない記憶装置のこと。いわゆるSSDなど。

さて前述のPCIe-SSDは標準化された仕様は無く、ベンダ各社が思い思いに仕様を決定していました。結果としてドライバがOSに標準で搭載されていなかったり、ツール類がベンダ独自のものだったりといった辛い状況を生みました。

そこで、2011年にPCIe-SSDを共通ドライバで扱うためにデバイス側も共通化しようという趣旨のNVMe仕様が策定されました(ご参考: NVMeの歴史)。

NVMe仕様とは「OS/ソフトウェアがNon-Volatile Memoryを扱うための、レジスタレベルのインターフェースの仕様」です。具体的にはレジスタマップ・Read/Write Commandのフォーマット・Commandを投入するためのQueueの構造などを定義しています。

逆にNVMe仕様では、デバイスの形状(Form Factor)やコネクタの形状は定義していません。ですので、NVMeに対応しているデバイスには、後述の製品のように、PCIe Cardの製品、2.5″ Small Form Factor(SFF)の製品、M.2形状の製品があったりします。
また、実はNVMe仕様はPCIe接続されたSSDに最適化されているものの、記憶素子も規定していなかったりもします。今はNANDの製品がほとんどですが、将来的には別の素子が利用されるかもしれません。

NVMe仕様に準拠したデバイスとしては以下のような製品があります:

Intel SSD 750など、2.5″ SFFの製品は従来のSATA/SAS SSDと同じ形状に見えますが、接続はPCIeになっています。

M.2(NGFF)

M.2仕様(以前はNGFF(Next Generation Form Factor)と呼ばれていました)は小型のデバイス用の形状・コネクタの仕様です。プロトコルとしてはPCIe/SATA/USBに対応しており、NVMe対応のSSDも実現可能です。

ノートPCやIntel NUCで採用されている他、サーバでの採用例も出てきました(ご参考: HP Moonshot, Microsoft OpenCloudServer)。

前述のようにM.2はPCIe/SATA両対応ですので、購入の際にはマザーボードとSSD両方がPCIeなのかSATAなのか確認しましょう。つながらないと大変かなしいことになります。

おわりに

それぞれのtopicについてもっと詳細に語りたい気持ちはやまやまですが、まずはざっくりSSD関連のtopicを紹介させていただきました。

各社のPCIe-SSDは今NVMe対応製品がちょうど出荷され始めたころです。今後はNVMeにシフトしていくはずですので、DMM.comのインフラに投入されているPCIe-SSDも順次NVMeに置き換わっていくはずです。

他にもSSDは新製品・新仕様が出てくると思いますので、引き続き関連動向に着目していこうと思います。

 

p.s. 最近おすすめのライトノベルはご注文はうさぎですか?のKoi先生が挿絵を描いている魔法少女禁止法です

OpenStack, コラム, 小ネタ

おはようございます。ライトノベル好きの新人ツチノコです。今後もよろしくお願いします。

さて本題ですが、こちらにあるOpenStack 各Distributionの概要を表にまとめました。
(ただ、CiscoのMetaCloud買収・Red HatのeNovance買収などは反映されていないようです)

何かのお役にたてば幸いです。

Hadoop, クラウド, コラム, 運用管理

初めまして、tagomorisといいます。今回縁あってゲストでエントリを書くことになりました。実に感慨深い気分です。

さて本題ですが、DMM.comを含めた多くのWebサービス・インターネットサービスでは、今やデータの収集・処理・分析といったタスクが非常に重要なものになっていることは多くの方に賛同をいただけるものと思います。近年ではIoTというキーワードもよく話題になります。増え続けるデータの処理をどのようにするか、といった点に悩んでいるサービス事業者の方は多いのではないでしょうか。

この種のデータ処理・分析をどこでどうやって行うか、という問題は通常のWebサービスの開発とはかなり異なる知識と経験を要求されます。特にHadoopを中心とした分散処理基盤のデプロイとメンテナンスはこれまで多くの開発者を悩ませてきました。

一方、近年ではデータ処理・データ分析に特化したサービスもいくつも出てきました。自分でHadoopクラスタのセットアップ・運用をしなくても利用可能なこれらのサービスは特に開発者の少ないスタートアップで広く利用されるようになり、耳にされることも多いかもしれません。

このエントリでは、特にスタートアップ企業、あるいは既存企業の新規事業などにおいてデータ処理・分析基盤が必要とされるとき、どのような選択肢があるかについて概要を書いてみようと思います。

総論

まず原則ですが、これは極めて簡単で「サービスを使いましょう、作ってはいけません」です。

そのスタートアップ企業が何を専門とするかにもよりますが、多くの場合、それらの企業は自前のデータセンタなど持ってはおらず、またソフトウェアエンジニアの数もそう多くはないでしょう。そういった企業にとって自前の分散処理クラスタの保持と運用は金銭、エンジニアリングの両面で極めて高コストになります。

サービスを使う場合についてもいくつかの選択肢があります。日本国内でよく選択されているのは以下のあたりでしょう。

  • Amazon Elastic MapReduce
  • Amazon RedShift
  • Treasure Data
  • Google BigQuery

今のスタートアップ企業の多くがAWS上でサービスを展開しているだろうことを考えるとAmazon Elastic MapReduce(以下EMR)やAmazon RedShift(以下RedShift)がまず選択肢となるかもしれません。EMRはS3に格納したデータを処理するHadoopクラスタを一時的に起動できる便利なシステムで、Hive, Pig などのHadoop向けDSLなどの他に自分で記述・コンパイルしたMapReduce処理そのものを走らせることもできます。RedShiftは分析用途の分散データベースを起動できる他社にもあまりない高機能サービスです。

数年前に登場したTreasure Data社のサービスはフルマネージドHadoopとでも言うべきもので、裏側で動いている仕組みとしてはHadoopとHive(あるいはPresto)ですが、クラスタの管理やデータ保管はすべてサービスの一部として提供されており、ユーザが面倒を見る必要がない、という点が異なります。
また保管データがスキーマレスなので、データ投入側からはいつ・どのようなタイミングでもデータの内容を変更することが可能です。これは特にサービス内容を頻繁に変更するスタートアップには良いかもしれません。

Google BigQuery(以下BigQuery)は少し趣の異なるサービスで、サポートされている言語はSQL-Likeな言語一種類のみです。実行時に裏側で何が起きているのかは基本的には隠蔽されており、実際に裏側はHadoopではありません。スキーマ管理やデータ保存などもBigQueryの一部として提供されており、フルマネージドサービスのひとつと言えるでしょう。
Googleの保有する巨大なクラスタで膨大な数での並列分散処理が行われることが特徴で、大容量データに対するクエリでもかなり速く結果が返ってくることが特徴です。ただしGoogleのクラウドサービスらしく、ちょくちょくクエリの失敗などが起きるため、ユーザ側で適宜リトライしてやらなければならない、などの注意点もあります。

さてスタートアップ企業にどのサービスが向いているかということを考えると、AWSのユーザにとって、EMRやRedShiftは利用例も多くとっつきやすいとも言えるかもしれません。一方で効率的に利用しようと思うと、EMRはHadoopの、RedShiftは分散データベースの知識が必要とされ、そのあたりの知識をもったエンジニアがいなければ高パフォーマンスの利用は難しくなるケースも多いでしょう。スキーマの調整やデータ保管形式・場所・期間などの管理も自分でやる必要があり、手をかければ便利に使える一方で、手をかけることができなければデータ量やクエリ回数に対して高い利用料金となってしまうケースもありそうです。

BigQueryはGoogle Cloud Platformの1サービスということになりますが、特にGoogleのクラウドサービスを使っていなくても簡単に利用できます。実際にAWS EC2を使っていながらデータ分析にはBigQueryを利用しているケースは多いようです。また現状(2015年2月)では利用料金が突出して安く、なんとBigQueryのデータ保存料金はAmazon S3の料金よりも安いのです。スキーマ管理が行われていること、直接クエリを実行可能であることを考えると、これは驚くべきことです。クエリ実行料金を含めても安く、自分が聞いたところでは数億行/dayもしくはそれ以上の規模のデータで運用していても月に数百ドル(桁を間違えてないよ!)の費用で済んでしまった、という話もあります。既にFluentdを用いていれば、データ投入はプラグインをひとつ足すだけでできてしまうという導入の簡単さも魅力かもしれません。

FluentdといえばTreasure Dataのサービス、という選択肢もあります。こちらもFluentdの設定ひとつで簡単にデータを投入できる上、BigQueryでは必要なデータのスキーマ管理が不要という利点があります。フルマネージドサービスとしてBigQueryと比較してみると、クエリの安定度ではこちらの方が上かもしれません。
またクエリのスケジュール実行や外部データベースへのデータ連携など、他のサービスが持っていない機能をいろいろ有していることも特徴です。少し高めの料金を払ってでも可能な限り外部サービスを利用して社内エンジニアリングコストを下げようと思うのであれば、有力な選択肢になることでしょう。

いくつかの特例となるトピック

総論としては以上のようになるのですが、特に上述の総論から逸脱するケースがいくつかあります。その中でもぱっと思いつくものに以下のものがあります。

  • 機械学習やグラフ処理などが主たる処理内容になるケース
  • 既に大規模なデータセンタを自社で保有しているケース
  • データを自社外に出すだけで事業リスクになるケース
  • 風土として自社でホストするというケース

まず目的とするデータ処理が主に機械学習やグラフ処理となる場合ですが、こういった種類の処理をホストしているフルマネージドサービスは実質的に無いといってよいでしょう。なのでこの場合、Amazon EMRの使用を検討するか、あるいは自社でHadoopクラスタをホストするということが有力な選択肢となります。特にSparkの新しいバージョンを使用したいなど、EMRのアップデートを待っている余裕がなく、またそれが事業において重要な価値を持つ場合には自社でHadoopクラスタをホストするのが重要な選択肢になるかもしれません。一方Treasure DataではHivemallというHiveのUDFとして動作するライブラリもサポートしていますから、このライブラリがサポートする範囲の処理だけを行いたいということであればTreasure Dataのサービス利用も選択肢としては有効となります。

既に大規模なデータセンタを自社で保有している場合ですが、このケースであればHadoopクラスタの調達・運用コストは下がります。ハードウェアやOSの運用のためにITインフラ運用の専門チームがいるのであればなおさらでしょう。しかしHadoopそのものの運用・アップグレードなどにかかるコストなどは過小評価するべきではなく、慎重に判断する必要があると言えます。

扱うデータが非常にセンシティブなものである場合にも注意が必要かもしれません。実質上、現在の各種クラウドサービスにおいて、技術的な問題による情報漏洩のリスク等はほとんど考慮する必要はないと思います。しかし非常にセンシティブなデータを他社管理のストレージに置いているという話が公表される際、その話の伝わり方がある種の誤解を含んでしまう可能性はあります。一度の風評被害がサービスの継続において決定的な悪影響を及ぼしかねないようなケースでは、そもそも外部にデータを最初から置かない、という選択肢もあるかもしれません。

また最後に、会社の風土あるいはポリシーとして自社でHadoopクラスタをホストする、というケースも考えられます。外部サービスに依存せず可能な限り自社内でOSSを利用して解決する、という選択をとる会社は多くはないものの存在します。エンジニアの採用や動機付け面の理由であることが多いでしょうか。これはこれ、というか、他人が口を出すことではないですね。

まとめ

主にスタートアップのような状況の各社においてデータ処理・分析基盤を必要とする場合において、主にどのような選択肢があるか、どういった判断基準でそれらを採用すればよいかについて簡単に述べました。

最初はもうちょっと広い範囲を見渡した内容で書こうかと思っていたのですが、あまりに長文になりそうだったので今回は主旨に合わないかなあと思ってダイジェスト版でお送りいたしました。フルバージョンを読みたい方はコメント欄やブックマークコメントにわっふるわっふると書いてください。と思いましたが自分のブログじゃないんでした。

このエントリの内容がみなさんの参考になることがあれば幸いです。

iDC, コラム, ネットワーク, 運用管理

こんにちは。ゲストブロガーのあきみちです。今回は、大量のサーバ群がどのように管理されているのかに関する導入です。

ペットから家畜へ

10年前と比べると、サーバ管理のトレンドが大きく変わっています。どういった変化が発生しているのかに関して、昔は一台一台のサーバをペットのようにかわいがっていたが、最近は家畜のようにまとめて扱う、というアナロジーが2012年頃から言われるようになっています。

そのアナロジーの元となっているのは、恐らく、2012年4月に行われた「Architectures for open and scalable clouds」という発表です。

一般的な大規模Webサイトのほとんどが、大量のサーバを少人数のスタッフで管理しています。DMMでも、一人あたり数百台のサーバをみつつ、全体では数千台のサーバが運用されています。サーバ台数あたりのエンジニア数を見ると、一台一台のサーバを愛玩動物のように愛でるのではなく、家畜のようにまとめて運用する必要がでてくることがわかります。

L3視点で見るネットワーク構成

「家畜」のようにある程度まとめて管理が行われているサーバ群ですが、それらをどのように管理しているのかを説明する前に、まずはどのようなネットワーク構成になっているのかを紹介します。「○○というサービスだと××を使っていて。。。」といった説明をしようと思ったとき、何がどこにどのように配置されているのかを理解しないと意味不明になってしまうためです。

DMMのサーバ群は、基本的に東京にある3ヶ所のデータセンターで運営されています。

東京1と東京2の構成は、図1のように一般的なWeb3層構成になっています。グローバルIPv4アドレスがついたロードバランサの裏側に、アプリケーションサーバがプライベートIPv4アドレス空間で運用されています。アプリケーションサーバが運用されているプライベートIPv4アドレスのネットワークも必要に応じて別れています。

4-1
図1:東京1と東京2の構成概要

アプリケーションサーバのさらに裏には、データベース用のプライベートIPv4アドレス空間があります。データベース用のネットワーク上では、MySQLのマスターとスレーブ、memcached、Redis、あわせて1000台程度が運用されています(本稿執筆時点)。

memcachedとRadisは、MySQLよりも高速な動作が必要な部分で利用されていますが、memcachedがRead専用の揮発性キャッシュとして利用され、Redisが不揮発性のKVS(Key Value Store)として利用されています。Redisは、主にオンラインゲームのセッション情報を管理するために利用されます。

ロードバランサ

DMMネットワーク全体で利用されているロードバランサは約60台です。ロードバランサはL4だけではなく、L7ロードバランシングも行っており、URLによってアプリケーションサーバを切り替えています。

たとえば、「DVD/CDレンタル」のURLは「http://www.dmm.com/rental/」から開始するようになっていますが、そのURLの場合にはこのアプリケーションサーバが処理を行う、といった動作です。A10 Networksの機器が主に利用されています。

アプリケーションサーバ

アプリケーションサーバはサービス毎に役割がわかれています。DVDレンタルなど、大きく分けると10種類以上のサービスグループに分けて、2000台以上が運用されています。

なお、オンラインゲームは外部のDMMネットワーク内部ではなく、パブリッククラウドで運用される場合もあります。認証部分等のみがDMM内部で行われ、ゲームコンテンツ等は外部のパブリッククラウドなどで運用されるといった形態です。

データセンター間の接続

東京1、東京2、東京3の全体構成は、図2のようになっています。

4-2
図2:東京1、東京2、東京3の全体構成

東京2と東京3は、IPv4グローバルセグメント及びIPv4プライベートセグメントがダークファイバによって同じL2セグメントとして運用されています。東京3はグローバルIPv4アドレスによる外部接続を行っておらず、東京2経由でインターネットとの通信が行われます。

東京1と東京2が別々のアイランド(BGP island)としての運用されています。東京1と東京2は異なるAS番号で運用されており、それぞれBGPルータでインターネットに接続しています。そのうえで、東京1と東京2はBGPピアリングを行っています。

東京1と東京2のグローバルIPv4アドレス空間が個別ASで運用される一方、プライベートIPv4アドレスによるアプリケーションサーバ用セグメントとデータベース用セグメントは、ダークファイバで直接接続されており、それぞれ同じL2セグメントとして運用されています(JuniperのQFabricが使われているのは、この部分です)。

次回予告

今回は、主にオンラインゲームなどを念頭にネットワーク構成を紹介しました。

動画配信部分は、これとは多少異なる構成になっています。次回は動画トラフィックがどのように配信されているのかを紹介する予定です。

この連載の過去記事

co-location, iDC, インフラ全般, コラム, ネットワーク

こんにちは、ゲストブロガーのあきみちです。

前回記事で紹介したように、DMM.comにとってのデータセンターは「サーバや通信機器を置く場所を借りるところ」です。セキュリティが確保された場所で、とまらない電気が供給され、適切な温度管理が行われた不動産なのです。

そのように表現すると、「あれ?iDCってインターネットデータセンターだよね?ネットワークは???」と疑問に思われるかたも多いと思います。そうなんです。データセンターに置かれた機器と外部との通信をどのように実現するのかも、データセンターを利用するうえで非常に大事なポイントなのです。

しかし、ネットワークそのものをデータセンターが直接提供しているかというと、必ずしもそうとは限りません。今回は、DMM.comが行っている手法にフォーカスしつつ、データセンター利用者が回線を確保することに関して紹介します。

データセンターでの通信手段確保

データセンターは非常に特殊な不動産事業であり、通信事業者であるとは限りません。そのため、データセンター事業者が直接通信回線を提供するのではなく、データセンター事業者と提携した通信事業者が回線部分を担うこともあります。

さらにいうと、データセンターを利用する顧客によってどのような通信回線が必要となるのかも違います。インターネットに直接接続された回線を必要とする顧客もいれば、広域な社内ネットワークの延長線上にデータセンターのコロケーションを位置づけて運用している顧客もいます。

そういった事情もあり、データセンター事業者が直接通信回線を提供するというよりも、むしろデータセンター事業者に構内配線の依頼をするといった形になりがちです。では、実際にどういう用途なのかの例を紹介していきましょう。

同じデータセンター内に通信事業者が入居している場合

様々な事業者が入居しているデータセンターもあります。

たとえば、データセンター内にIX(Internet eXchange。別記事で解説します)であったり、インターネットプロバイダやインターネットサービスプロバイダ、長距離通信を行うキャリアが入居している場合もあります(長距離通信キャリアがデータセンター事業者という場合もあります)。

IXが入居しているデータセンターを利用している顧客は、IX事業者までの構内配線をデータセンター事業者に依頼することで、他の事業者とのBGPによるピアリングを行える環境を手に入れます。同様に、データセンター事業者に構内配線を依頼することで、インターネットプロバイダなどからインターネット接続サービスを購入することもできます。

データセンターでの構内配線のイメージ
データセンターでの構内配線のイメージ

どのような事業者が、そのデータセンターに入居しているのかが、データセンターそのものの価値を上昇させる要素になるのです。各種事業者との接続が構内配線のみで行えるのは、「便利なデータセンター」なのです。

そして、そういった「便利なデータセンター」に様々な重要設備が集中しがちです。経済原理によって構築された「情報の密集地帯」となっているデータセンターも存在するわけです。

さて、次に、DMM.comの東京データセンター1での事例を見てみましょう。

東京データセンター1にあるコアルータ
東京データセンター1にあるコアルータ

まず、以下の写真がDMM.comの東京データセンター1で運用されているコアルータです。Juniper MX480が2台構成になっています(排気の関係などから1ラックに積まれてしまっているようです。「本当は別ラックに分けた方がいいのだけど。。。」らしいです)。

この写真にあるデータセンターでは、構内配線を経由してピアリングやトランジットを行っています(ピアリングやトランジット、IXなどに関しては別途記事を書く予定です)。同じデータセンター内にエリアを借りている他の事業者と構内配線で接続しているのですが、それが「インターネットとの接続」になるのです。そのため、通信機器を見ても単に普通に光ファイバで繋がっているだけのように見えます。

なお、余談ではありますが、写真を撮影した後に、「あ!養生テープタグのままだった!ツチノコブログにそのまま写真を掲載しちゃうのは多少恥ずかしいかも」と言っていましたが、その後、「格好悪い部分も含めて晒すのが漢」とか意味不明な主張をされていました。

他の場所へのダークファイバ

構内配線で他の組織に繋がることによって外部との通信手段を確保する手法は、データセンターの外との通信を他の事業者に外注することを意味します。

しかし、その方法では、間に他の事業者が提供するルータなどの通信機器が介在することになりがちです。目的によっては、間に他の事業者が提供するルータなどを経由させずに直接自社が運用する機器同士を接続したい場合もあります。

そのような場合には、ダークファイバを借りるという手法が採用されることがあります。ダークファイバは、長距離の光ファイバをそのまま借りれるサービスです。光が通っていない状態で提供されることからそのように呼ばれています。

ダークファイバを使って通信を行える距離は、その光ファイバに接続された通信機器のネットワークインターフェースによって変わってきます。たとえば、10GBASE-LRを使った場合には最大10km、10GBASE-ERを使った場合は最大40kmまでの通信が可能です。10km以内に存在しているデータセンター同士であれば10GBASE-LRで、40km以内に存在しているデータセンター同士であれば10GBASE-ERで、そのまま直接接続できるのです。

DMM.comは、ダークファイバを10GBASE-ERで利用して東京都内のデータセンター同士を接続しています。このダークファイバをJuniperによるファブリック(ファブリックに関しては別途記事を書く予定です)の一部であったり、バーチャルシャーシを構成する回線として使ったりしています。通常の長いシングルモードファイバとしてダークファイバをそのまま利用した形です。

EX 4200のバーチャルシャーシ機能をダークファイバで
EX 4200のバーチャルシャーシ機能をダークファイバで

DMM.comでは、そのような運用を行っていませんが、たとえば、WDM装置を用意して複数波長を一本のダークファイバに乗せるといった用途も考えられます。

その他の方法

データセンター外との通信回線がダークファイバに限定されているわけではありません。

ダークファイバ以外にも、長距離伝送サービス(Optical Transport Networkを用いた数百〜数千kmの長距離伝送など)の購入や、IPパケットの中にIPパケットをカプセル化したうえでそれを暗号化したVPN(Virtual Private Network)の利用といった手法でデータセンター外部との通信回線を確保することが可能です。DMM.comでは、東京のデータセンターから九州のデータセンターまでVPNを利用した接続を行っています。

その他、データセンター事業者がネットワークの提供を行う場合もあります。たとえば、データセンターが持っているIPアドレスブロックが顧客に提供されるといったサービスもあります。データセンター事業者がインターネット接続を提供する上位プロバイダになるというものです。

最後に

ここで紹介しているのは、主にDMM.comが採用している手法です。データセンターと外部の通信手段を確保する方法は、この他にも様々なものがあります。何をしたいかによって回線を確保する方法も変わりますし、新しい技術やサービスが産まれることによっても色々変わってきます。

OSI参照モデルの7層構造を念頭に、電源や配線が「レイヤー0」と呼ばれることもありますが、インターネットはこのような物理的な設備や回線によって構築されているのです。ユーザとして使う場合のインターネットは「繋げば使えるもの」であるように見えがちですが、インターネットそのものを構成している物理的な機器や回線を取り巻く商習慣は意外と生々しいものだったりします。

PAGE TOP