結論：NFSとは「別のコンピュータのフォルダを、自分のPCのフォルダのように使える」仕組み

NFS（Network File System）とは、ネットワーク越しに他のコンピュータのディスク（フォルダ）を、自分のローカルディスクのように扱えるようにする通信プロトコルです。

一言でいうと、

「遠くにあるフォルダを、手元にあるかのように使える技術」

これがNFSの本質です。

NFSはもともと Sun Microsystems によって開発され、現在ではLinux/Unix系システムを中心に、サーバ環境で広く使われています。

そもそも「ファイル共有」が必要になる理由

まず前提として、現代のシステムでは次のような状況がよくあります。

• サーバが複数台ある
• それらが同じデータを参照する必要がある
• 画像・帳票・ログ・アップロードファイルなどを一元管理したい

例：

• Webサーバが3台ある
• どのサーバからアクセスしても同じ画像フォルダを使いたい

このとき各サーバに同じファイルをコピーして回るのは現実的ではありません。

そこで登場するのが NFS です。

NFSの基本的な仕組み

登場人物はたった2つ

NFSは、とてもシンプルな構成です。

サーバ側で共有設定したディレクトリを、クライアント側で mount（マウント）すると、クライアントからは普通のフォルダとして見えるようになります。

構造を簡略化すると、次のようになります。

[NFSクライアント] ─── ネットワーク ─── [NFSサーバ]
        |
     /mnt/share   ← 実体はサーバ側ディスク

ポイントはここです。

• クライアントから見ると /mnt/share は普通のフォルダ
• しかし実体はNFSサーバ上に存在

アプリケーションは「ローカルファイル」だと思って読み書きしますが、裏ではNFSがネットワーク越しに通信しています。

NFSを使うと何が嬉しいのか？

代表的なメリットは次の3つです。

1. アプリケーションを変更しなくてよい

NFSは「ファイルシステム」として見えるため、

• 特別なAPI
• 専用ライブラリ

が不要です。

既存アプリはそのままで、

/data/file.txt

を読むだけ。
それがたまたまNFSなだけ、という状態になります。

2. 複数サーバで同じデータを共有できる

典型構成：

WebサーバA ─┐
WebサーバB ─┼─ NFSサーバ
WebサーバC ─┘

これにより、

• アップロードファイル
• 画像
• 帳票

などを1か所に集約できます。

3. 構成がシンプル

最低限必要なのは：

• NFSサーバ
• NFSクライアント

だけ。

大規模な分散ストレージと比べると、導入・理解・運用のハードルが低いのも特徴です。

ローカルディスクとNFSの違い

感覚的な違いを表にまとめます。

見た目は同じ、裏側が違う。
これが最大のポイントです。

超かんたん：NFSの利用イメージ（概念）

サーバ側（共有する）

/share

というフォルダを公開。

クライアント側（使う）

mount サーバ:/share /mnt/share

すると、

/mnt/share

が現れ、普通のフォルダとして操作可能になります。

以降は：

• ls
• cp
• vi

すべて通常通り。

実務で必ず意識すべき注意点

便利なNFSですが、設計時には以下が重要です。

● ネットワーク＝性能

ファイルI/Oはすべてネットワーク越し。
大量アクセス時はボトルネックになります。

● NFSサーバは単一障害点になりやすい

NFSサーバが落ちると、

→ 接続している全クライアントが影響を受けます。

冗長化設計が重要になります。

● 同時書き込み

複数マシンから同じファイルを書く場合、

• ロック
• 整合性

を意識しないと事故が起きます。

まとめ

最後に要点を整理します。

• NFSとは「遠隔フォルダをローカルのように使える」プロトコル
• サーバが公開、クライアントがマウントするだけ
• アプリは通常のファイル操作のまま利用可能
• 複数サーバでのデータ共有が簡単
• 一方で、性能・単一障害点・同時更新には注意が必要

スタンドアロンという単語を聞く機会が増えつつある昨今、その形態にはメリットもデメリットもあり、用途に応じて最適な選択が必要です。

この記事では「スタンドアロン」の基本的な概念から具体的な用途、メリット・デメリットまでをIT初心者向けにわかりやすく網羅的に解説します。

プログラマーやシステムエンジニアを目指す方であれば知らないと恥ずかしい超・基本知識の１つ。是非最後までご覧ください。

スタンドアロンとは

スタンドアロンとは、１台のコンピュータやソフトウェアが他のシステムやデバイスと独立して、自己完結型で機能する形態を指します。つまり、自分以外のコンピューターやソフトウェアなしでその機能を十分に発揮できる状態です。

スタンドアロンという言葉は、英語で「stand alone」から来ています。この「stand alone」は直訳すると「単独で立つ」という意味になります。

分かりやすく言えば「電卓」がスタンドアロンで利用される仕組みの一例。「電卓」はそれ自体で計算するという機能を完全に果たし、他のコンピュータや他の電卓と接続したりする必要はありません。

このスタンドアロンと対照的な概念の１つが「ネットワークシステム」です。ネットワークシステムは複数のデバイスやソフトウェアが連携して機能するため、単一の部分が独立して完全に機能するわけではありません。

参考　ネットワークとは？

つまり、例えばコンピュータから写真を印刷したい！という場合には、有線か無線かを問わずプリンターに接続する場合があります。これはスタンドアロンではありません。

インターネットも、ネットワークを介してサーバと接続する必要があるため、これもスタンドアロンではありません。

スタンドアロンの具体例

ここでは、スタンドアロンが具体的にどのような形で存在するのか、いくつかの代表的な例をご紹介します。

パーソナルコンピュータ

パーソナルコンピュータ（PC）はスタンドアロンで動作します。インターネットに接続していなくても、ローカルに保存されたソフトウェアを使って作業ができるのが一例です。

ネットに接続していなくてもwordで文章を作成したり、動画を編集したりすることが可能。ネットやプリンターなど、他のコンピュータやサーバを接続しないで利用する状態がスタンドアロンです。

サーバー

一部のサーバーもスタンドアロンで動作する場合があります。特に小規模なビジネスや研究施設で使われるサーバーは、ネットワークに接続されていなくても特定の処理を行うことができます。

参考　サーバとは？

一例が工場や発電所などの制御システムで用いられるサーバーです。このサーバはセキュリティ上の理由からインターネットから隔離された環境で動作することが多く、これらのサーバーは特定の制御タスクを独立して行い、外部との通信は最小限に抑えられます。

ソフトウェア

多くのソフトウェアにはスタンドアロン版が存在します。これはインターネット接続なしで完全に動作するソフトウェアで、例えばAdobe Photoshopのスタンドアロン版がそれに該当します。

ザックりいえば、インターネット接続無しで自由にその機能を操作できれば、そのソフトウェアはスタンドアロンで利用される（利用できる）と言えます。

IoTデバイス

一部のIoT（Internet of Things）デバイスもスタンドアロンで動作することがあります。例えば、スマート電球はスマートフォンと直接Bluetooth接続でき、中央のハブなしで操作が可能です。

スタンドアロンのメリットとデメリット

スタンドアロンは特定の状況下で多くの利点を提供しますが、それには一定の制限や短所もあります。このセクションでは、そのメリットとデメリットを詳細に解説します。

メリット

1. セキュリティ
   • インターネットに接続されていないスタンドアロンシステムは、外部からの攻撃に対して比較的安全であると言えます。例えば、外部からの攻撃に晒されたくないような機密システムの場合は、あえてインターネット接続せず、ネットワークから隔離して運用する場合があります。
2. 独立性
   • ネットワーク障害が発生しても、スタンドアロンシステムは影響を受けません。ポイントオブセール（POS）システムなど、ビジネスにおいて継続的な動作が必要な場合に有用です。
3. シンプルな設定
   • スタンドアロンシステムは基本的にネットワーク設定や複雑な依存関係を必要としません。このため、導入と運用が比較的簡単です。

まとめると、外部からの独立性が担保されるので、セキュリティ的に安心、かつ外部への接続設定などが不要なので、ネットワークの知識が無くても比較的容易に開発・運用が可能である！ということです。

デメリット

1. 機能制限
   • スタンドアロンシステムは、ネットワークリソースや外部データにアクセスできないため、その機能が限られる場合があります。例えば、最新の天気予報などを必要とするシステムなどはスタンドアロンでは運用できません。
2. データ同期の問題
   • 他のシステムやデバイスとのデータ同期が困難です。医療機関で患者データを共有する必要がある場合などに問題となる可能性があります。
3. 高い運用コスト
   • インターネットを活用しないため、ソフトウェアのアップデートやメンテナンスが手動で行わなければならない場合があり、これが逆に時間とコストを必要とする場合があります。

他のコンピュータやサーバと機能を共有できないので、その分のメリットを享受できません、ということです。

スタンドアロンを選ぶべき状況

スタンドアロンはその特性上、特定のケースで非常に有用だということが分かります。しかし、そのようなケースはどのようなものなのでしょうか？

ここでは、スタンドアロンシステムが特に力を発揮するシナリオを例示したいと思います。

パターン１：高いセキュリティが求められる場合

セキュリティが極めて重要な場合、スタンドアロンシステムは大きな価値を持ちます。例えば、政府機関や研究施設で扱う機密情報が該当します。こうした環境では、外部との接触点を極力減らし、セキュリティリスクを低減することが求められます。

特に、特許取得を目指すような専門的な研究機関のシステムや、決して外部へのデータ流出が許されない重要な個人情報を扱うシステムなどが↑に該当します。

パターン２：ネットワークに依存しない業務を行う場合

もし業務がインターネット接続に依存していないのであれば、スタンドアロンのシステムが有用です。例を挙げるならば、古い書籍や資料をデジタル化する図書館のスキャンシステムなどがあります。

こうした作業は基本的にはネットワークに依存しないため、スタンドアロンのシステムで効率的に行えます。

パターン３：独立したシステムで完結するサービスを提供する場合

例えば、博物館や展示会で使われるインタラクティブなディスプレイは、その場で完結する情報提供を行います。ネットワークに繋がっている必要がないため、スタンドアロンのシステムとして設計されることが多いです。

パターン４：運用がシンプルであるべき状況

あまりにも複雑なシステムは、故障のリスクを高め、運用に専門的な知識が必要となります。スタンドアロンシステムは通常、運用がシンプルで、問題が起きた場合の対処も容易です。これは、中小企業や非専門家が操作する状況で非常に有用です。

まとめると、キーワードは「セキュリティ」です。セキュリティ対策にはコストがかかります。そのコストを省けるなら省く、コストがネットワーク接続のメリットを上回るならつながない。これが原則です。

この記事では認証の方法として広く一般的に利用されているJWT（JSON Web Token）について解説します。

JWTとは？

JWT（JSON Web Token）は、ユーザーの認証情報やその他のデータを安全にやり取りするためのトークン形式の標準規格です。JSON形式でデータを保持し、署名を付けることでデータの改ざんを防止します。

簡単に言うと、JWTは「安全な情報のやり取りを実現するためのデジタルなパスポート」のようなものです。

JWTを使うメリット

JWTを使うことで、以下のようなメリットがあります。

セッション認証との違い

従来のセッション認証では、ユーザーがログインするとサーバー側でセッション情報を保持し、ユーザーにはセッションIDが付与されます。しかし、この方法ではサーバー側に状態を持つため、サーバーの負荷が増えたり、負荷分散が難しくなったりします。

一方、JWTではサーバーが状態を持たないステートレスな認証が可能です。これにより、サーバーの負荷を軽減し、複数のサーバー間での負荷分散が容易になります。

JWTの仕組み

JWTは以下の3つの部分から構成されています：

1. ヘッダー（Header）
2. ペイロード（Payload）
3. 署名（Signature）

これらはそれぞれBase64URLエンコードされ、ピリオド（.）で区切られて結合されます。

1. ヘッダー（Header）

トークンのタイプ（JWT）と署名アルゴリズムの情報が含まれます。例：

{
  "alg": "HS256",
  "typ": "JWT"
}

2. ペイロード（Payload）

ユーザー情報や有効期限などのクレーム（属性）が含まれます。標準クレームの例：

• iss：発行者（Issuer）
• sub：主体（Subject）
• exp：有効期限（Expiration Time）

例：

{
  "sub": "1234567890",
  "name": "山田太郎",
  "admin": true,
  "iat": 1516239022
}

3. 署名（Signature）

ヘッダーとペイロードを結合し、秘密鍵でハッシュ化したものです。これにより、データの改ざんを検出できます。

参考　共通鍵暗号方式/公開鍵暗号方式とは？初心者向けに３分でわかりやすく解説

JWTの生成と検証の流れ

1. ユーザー認証：ユーザーがログイン情報を送信します。
2. トークン生成：サーバーがユーザー情報を元にJWTを生成します。
3. トークン送信：生成したJWTをユーザーに返します。
4. リクエスト時のトークン送付：ユーザーは以降のリクエストにJWTを含めます。
5. トークン検証：サーバーは受け取ったJWTを検証し、リクエストを処理します。

JWTの実装方法

JWTを実装するには、以下の手順を踏みます。

ステップ1：ライブラリの導入

各プログラミング言語には、JWTを扱うためのライブラリがあります。例えば：

• Node.js：jsonwebtoken
• Python：PyJWT
• Java：jjwt
• PHP：firebase/php-jwt

ステップ2：トークンの生成

ユーザーが認証されたら、サーバー側でトークンを生成します。例（Node.js）：

const jwt = require('jsonwebtoken');
const payload = {
  userId: user.id,
  name: user.name
};
const token = jwt.sign(payload, '秘密鍵', { expiresIn: '1h' });

ステップ3：トークンの送信

生成したトークンをユーザーに返します。HTTPヘッダーのAuthorizationに含めるのが一般的です。

res.header('Authorization', 'Bearer ' + token);

ステップ4：トークンの検証

ユーザーからのリクエストを受け取ったら、トークンを検証します。例（Node.js）：

const token = req.headers['authorization'].split(' ')[1];
jwt.verify(token, '秘密鍵', (err, decoded) => {
  if (err) {
    return res.status(401).send('トークンが無効です');
  }
  req.user = decoded;
  next();
});

セキュリティ上の注意点

JWTを安全に使用するためには、以下のポイントに注意が必要です。

秘密鍵の管理

署名に使用する秘密鍵は、厳重に管理しましょう。漏洩すると、トークンが偽造されるリスクがあります。

有効期限の設定

トークンの有効期限を適切に設定し、長期間有効なトークンを避けます。短い有効期限にすることで、万が一トークンが盗まれても被害を最小限に抑えられます。

HTTPSの利用

通信を暗号化するために、HTTPSを使用しましょう。これにより、中間者攻撃によるトークンの盗聴を防げます。

不要な情報を含めない

トークンには必要最低限の情報だけを含めましょう。機密性の高い情報を含めると、セキュリティリスクが高まります。

よくある間違いと対策

JWTの実装で陥りやすいミスと、その対策を紹介します。

署名なしのトークンを受け入れてしまう

署名がない、または無効なトークンを受け入れてしまうと、セキュリティが崩壊します。必ず署名の検証を行いましょう。

秘密鍵をコード内にベタ書きする

秘密鍵をコード内に直接記述すると、ソースコード管理システムから漏洩する可能性があります。環境変数や安全な設定ファイルを使用しましょう。

トークンの無効化ができない

JWTは一度発行すると、その有効期限内は有効です。ユーザーがログアウトした場合や、権限が変更された場合でもトークンが使えると問題です。対策として、ブラックリスト方式やトークンの短期化を検討しましょう。

JWTの活用事例

JWTはさまざまな場面で活用されています。

• WebAPIの認証：RESTful APIでのユーザー認証に利用。
• シングルサインオン（SSO）：一度のログインで複数のサービスにアクセス可能に。
• モバイルアプリとの連携：サーバーとアプリ間の安全な通信に利用。

まとめ

JWTとは、ユーザー認証と情報の安全なやり取りを可能にするトークン形式の技術です。サーバーが状態を持たないため、スケーラビリティが高く、現代のウェブ開発において重要な役割を果たしています。正しい実装とセキュリティ対策を行うことで、安全で効率的なシステムを構築できます。

この記事を通じて、JWTの基本から実装方法、注意点まで理解していただけたでしょうか。ぜひ実際のプロジェクトでJWTを活用してみてください。

WebAPI
├── RestAPI ←今回解説する対象
├── SOAP
├── GraphQL
└── gRPC

参考　WebAPIとは？（APIとは？）

結論を超ザックリいえば、REST APIは「リソース」に対して「HTTPプロトコル」を使って「操作」する方法で、各リクエストが独立して処理されるAPIと言えます。

このページではそもそもWebAPIって何？というところをおさらいしつつ、REST APIの概念を１からわかりやすくご説明します。

前提：APIとは何か？

API（エーピーアイ）は「Application Programming Interface」の略で、異なるソフトウェア同士が情報をやり取りするためのルールや仕組みを提供するものです。APIはその名の通りアプリケーションが他のアプリケーションの機能を使えるようにする「窓口」のような役割を果たします。

例えばスマートフォンの天気アプリは、気象データを提供するサービス（例えば、気象庁や気象会社）のAPIを使って最新の天気情報を取得します。（APIという「窓口」に知りたい気象情報を問い合わせ→回答を受け取ってくる。）このように、APIはアプリやサービスが他のアプリやサービスからデータを取得したり、機能を利用したりするために使われます。

また、その中でも特にインターネットを介して情報の交換が行われるものをWebAPIと呼びます。

REST APIとは

REST APIはWebAPIの１種。その中でも特に「REST」という設計原則に従ったAPIです。

WebAPI
├── RestAPI ←今回解説する対象
├── SOAP
├── GraphQL
└── gRPC

RESTは「Representational State Transfer」の略で、以下の４点が大きなポイントです。ザックリいえば、モノを「リソース」として扱い、そのリソースに対する操作を「HTTP」でリクエスト。これらのリクエストは単発で行われるということ。

それぞれのポイントの意味を１つずつ詳しく説明していきます。

REST APIの特徴１：リソース指向

リソース指向とは、APIがデータや機能を具体的な「モノ」として扱う方法です。

リソース指向を日常生活で例えると、「図書館で本を管理する方法」と考えるとわかりやすいです。

図書館の本、これがリソースです。それぞれの本には固有の識別番号（例えばバーコード）があり、この番号を使って本を特定することができます。このときのバーコードがURLに当たります。このURLと後述する「HTTPメソッド」を組み合わせて、「村上春樹の本」を「Get（HTTPメソッド）」して！というような形でリクエストするイメージがリソース指向。

対してリソース指向ではないのは、図書館の利用者が特定の目的や手続きを実行するためにリクエストを行うようなイメージになります。この方式では本自体をリソースとして扱うのではなく、利用者の目的や手続きに基づいて操作が行われます。つまり「村上春樹の本を取得して！」というように、モノとそれに対する操作をひとくくりにしたもの（＝手続き・アクション）がリソース指向ではない例。

REST APIはリソース（例えば、ユーザーや商品）を操作するためのものですが、リソース指向ではないAPIは「特定の手続きを実行するためのもの」と分けて考えると理解しやすいでしょう。

REST APIの特徴２：HTTPプロトコルを使用

REST APIは、HTTPプロトコルを使用します。

参考　HTTPとは？

HTTPプロトコルとは、簡単に説明すると「インターネットで情報をやり取りするためのルール」です。例えば私たちがWebサイトを見るとき、ブラウザはこのルールを使ってサーバーからページを取得し画面上にページ情報を表示します。REST APIも同じルールを使って、アプリやサービスがデータをやり取りするということです。

REST APIの特徴３：HTTPメソッドでリソースに対する処理を表す

HTTPメソッドは、インターネットでデータをやり取りする際に使用する特定の操作方法を指します。REST APIでは、主に4つのHTTPメソッド（GET、POST、PUT、DELETE）が使用され、これらを使って「リソース」の作成・取得・更新・削除を行います。

REST APIの特徴４：ステートレス

ステートレスとは、各リクエストが独立して処理され、サーバーがクライアントの状態を記憶しないことを指します。つまり、１つのリクエストが他のリクエストに依存しないということです。

参考　クライアントサーバシステムとは？

ファストフード店で食べ物を注文するとき、店員はあなたの過去の注文を覚えていません。あなたが来るたびに、注文を初めからやり直します。例えば、今日ハンバーガーを注文しても、明日また来たときに店員はそれを覚えていません。これは、各注文（リクエスト）が独立しているためです。

一方ステートフルの場合、昨日「ハンバーガーを1つください」と注文していたとしたら、今日来たときに「昨日と同じものをください」と言うだけで、店員は同じハンバーガーを出してくれます。また、今日は「追加でフライドポテトもください」と言えば、店員は昨日の注文にフライドポテトを追加します。

ザックリいえば、リクエストを投げる側と受ける側に、どれぐらい密接な関係があるか？というのが違い。

1. ステートレス
   • 関連無し。毎回初対面の関係性。
2. ステートフル
   • 密接に関連する。両者が手を握っているイメージ。

リクエストを受け取ってから30秒以内に終わらない場合はタイムアウトエラーにする、というような設定をすることで、長期間プロセスがリソースを占有することを防ぎます。

がしかし、そもそもなぜタイムアウトの設定を入れる必要があるの？といった疑問や、どのようにタイムアウト設計を行えばよいか？という点については、案外考える機会が少ないものかもしれません。このページでは、タイムアウト設定の理由、タイムアウト設定の基本ノウハウを初心者向けにわかりやすく説明していきたいと思います。

タイムアウト設定の必要性

まずは前段として、タイムアウト設定がなぜ重要かを理解するために、その理由と具体的な例を交えて説明します。

大きく分けて以下５点が主な理由。

理由１：システムの安定性向上

タイムアウト設定は、システムが無限に待機する状態を防ぐために必要不可欠な設定です。

例えば、Webアプリケーション経由でデータベースから情報を取得する際にデータベースがなかなか応答しない場合。もし、このときタイムアウトを設定していなければ、システムは応答が返ってくるまで無限に待ち続けることになります。その結果、メモリやCPUなどのリソースを常に消費し続けることになり、最悪の場合システム全体に悪影響を与えることに。

タイムアウト設定により、一定時間が経過した後に自動的にリクエストをキャンセルし、エラーメッセージを返すことで、他のリクエスト処理に移ることができます。

参考　Webサーバーとは？

理由２：リソースの効率的な利用

理由１と多少被りますが、システムのリソース（メモリやCPUなど）を効率的に利用するためにタイムアウト設定が役立ちます。例えば、データベースに大量のデータを保存する処理がなかなか終わらない場合、システムはメモリを使い続け、他の重要な処理ができなくなってしまいます。

ここで適切なタイムアウトを設定することで、一定時間で処理を打ち切り、リソースを他の処理に割り当てることができるようになります。

理由３：ユーザーエクスペリエンスの向上

理由の３つ目はUXの向上です。画面で何かしらのボタンを押しても、何の反応も帰ってこない画面・・・これ結構不満溜まりますよね。一定期間反応がない場合に、タイムアウトエラーを起こすことでUXの向上につなげることができます。

例えば、オンラインショッピングサイトで商品を検索する際、検索結果が表示されるまでに時間がかかりすぎると、ユーザーはそのサイトを使いたくなくなってしまうでしょう。タイムアウト設定を行うことで、一定時間内に結果が返ってこない場合はエラーメッセージを表示したりすることでユーザーに再度試してもらうよう促すことができます。

理由４：エラーの対処

タイムアウト設定をすることで、処理が終わらない場合のエラーハンドリングがしやすくなります。

例えば、外部のAPIを呼び出す際になかなか応答が返ってこない場合があります。この時、タイムアウトを設定しておくと、一定時間でエラーメッセージを出して次のステップに進むことができます。これにより、システムがエラーで停止するのを防ぎ、他の処理が継続できるようになります。

参考　APIとは？

３秒反応がなかったら、ログの書き込み処理に移る・・・というような感じですね。

理由５：サービスレベルアグリーメント (SLA) の遵守

サービスを提供する際に、一定の応答時間を顧客・クライアントとルールを合意する場合があります。これをサービスレベルアグリーメント（SLA）と言います。

例えば、クラウドサービスでは99.9%のアップタイムを保証することがよくあります。（=24時間365日のうち、0.01%時間以下の障害までは許容。それ以上は許容しない。）このSLAを守るためには、タイムアウト設定が必要です。タイムアウトを設定することで、一定時間内に応答がない場合に処理を打ち切り、システムの他の部分が影響を受けないようにしたりすることができます。

まとめ　タイムアウト設定が重要な理由

タイムアウト設計の基本

タイムアウト設定は、システムの安定性やパフォーマンスを確保するための重要な要素。ここでは、タイムアウト設計の基本の概要をご説明します。

1. 適切なタイムアウト時間の設定

タイムアウトの時間を設定する際には、システム要件やユーザーの期待に基づいて慎重に決定する必要があります。短すぎるタイムアウト時間は、頻繁にタイムアウトが発生しユーザー体験を損なう一方、長すぎるタイムアウト時間は、システムリソースの無駄遣いにつながります。

例えば、Webアプリケーションでデータベースにクエリを送信する際には、通常のクエリ処理時間に少し余裕を持たせたタイムアウト時間を設定します。例えば、通常のクエリ処理時間が1秒であれば、タイムアウト時間は3秒程度に設定します。

2. 動的なタイムアウト調整

システムの状態や負荷に応じて、タイムアウト時間を動的に調整する仕組みを導入すると効果的です。

例えば、トラフィックが急増した場合や、特定の時間帯にシステムの負荷が高まる場合には、タイムアウト時間を延長してリクエストの処理をスムーズに行えるようにします。逆に、負荷が低いときには、タイムアウト時間を短縮してリソースの無駄を減らします。

3. 詳細なログ記録

タイムアウトが発生した際に、その情報・経緯を詳細に記録することが重要。ログにはタイムアウトが発生した時間 / リクエストの内容 / 発生したコンポーネントなどの情報を含めることで、後で問題を分析し根本原因を特定して改善策を講じることができるようになります。

例えば、Webサーバーのログに「タイムアウトが発生したURL、クライアントのIPアドレス、リクエストの種類、タイムアウト発生時のシステム状態」などを記録するようなイメージ。

4. ユーザー通知

タイムアウトが発生した場合に、ユーザーに適切な通知を行うことも重要。ユーザーがタイムアウトの原因を理解し、次にどうすれば良いかを案内することでユーザエクスペリエンスの向上が期待できます。

タイムアウトが発生した場合に「現在サーバーが混雑しています。しばらくしてから再度お試しください。」といったメッセージを表示されるシステムもよく見かけますが、まさにあれが一例です。

5. フェイルセーフメカニズム

タイムアウト後の処理も考慮する必要（システムが自動的に復旧する仕組みを作る）もあります。この後処理を適切に設計することでシステムがタイムアウトによる影響を受けずに安定して動作し続けることができます。

例えば、外部APIへのリクエストがタイムアウトした場合には、内部のキャッシュから代替データを提供するか、別のAPIを呼び出すようにしたりするなど。これにより、ユーザーに対するサービスを途切れさせることなく提供できます。

タイムアウト設定を適切に設計することで、システムの安定性とパフォーマンスを保ちながら、ユーザーに対して高品質なサービスを提供することができます。

参考　APIとは？

RAMLには、APIがどのように動作するか？といった詳細なルールや構造・APIを通じて送受信されるデータの型や形式・APIのエンドポイント（接続点）・そしてそれらが受け取る入力（インプット）と返す出力（アウトプット）の具体的な規格などが含まれます。以下が簡単なサンプルです。

#%RAML 1.0
title: Users API
version: v1
baseUri: http://example.com/api/{version}

/users:
  get:
    description: Get a list of users
    responses:
      200:
        body:
          application/json:
            example: |
              {
                "users": [
                  {"id": 1, "name": "Alice"},
                  {"id": 2, "name": "Bob"}
                ]
              }

このページではRAMLの役割や、基本的な使い方・書き方を１からわかりやすく解説します。

RAMLとは？簡単に

RAMLはAPIの「設計図」を作成する手助けをするツールだと言えます。

例えば建築家は、家を建てる前にどのように家が見えるか、どの部屋がどこにあるか、どんな機能を持つかを紙の上で詳細に描きますよね。この設計図があることで、建築現場の人々は正確に家を建てるためのガイドラインを持つことができ誤解や間違いを減らすことができます。RAMLもこれと同じで、APIを開発するための設計図としての役割を担います。

ひとまずここでは、RAMLはAPIの設計図を作成するための言語であり、APIがどのように振る舞うべきか、どのようなデータを送受信するか、どのようにエラーを扱うかなど、具体的なAPIの骨格を表すものである！と覚えておきましょう。

RAMLの書き方

以下が冒頭にもお見せした簡単なRAMLのサンプルコードです。

このRAMLには何が書かれていて、どんな内容を定義しているのかを簡単に確認していきます。

#%RAML 1.0
title: Users API
version: v1
baseUri: http://example.com/api/{version}

/users:
  get:
    description: Get a list of users
    responses:
      200:
        body:
          application/json:
            example: |
              {
                "users": [
                  {"id": 1, "name": "Alice"},
                  {"id": 2, "name": "Bob"}
                ]
              }

1. RAMLバージョンの指定

#%RAML 1.0：文書の先頭にこの行を書くことで使用しているRAMLのバージョンを宣言します。この宣言を行っておくことでパーサー（解析器）が適切に文書を読み込めるようになります。

#%RAML 1.0

2. APIの基本情報

• title：APIの名前。
• version：APIのバージョン。
• baseUri：APIのベースとなるURL。URL中にはバージョン番号などの変数を埋め込むこともできます。

title: Users API
version: v1
baseUri: http://example.com/api/{version}

3. リソースとメソッド

• リソース：APIで扱うデータの「種類」や「項目」を示します。通常、URLのパス（例：/users）で表されます。
• メソッド：リソースに対する操作（HTTPメソッド）。get、post、put、deleteなどを定義します。

/users:
  get:

4. レスポンスとステータスコード

• レスポンス：APIがどのようなデータを返すか、またはどのようなエラーが返るかを定義。
• ステータスコード：レスポンスの種類を示すHTTPステータスコード（例：200、404、500）を指定。

/users:
  get:
    description: Get a list of users
    responses:
      200:
        body:
          application/json:
            example: |
              {
                "users": [
                  {"id": 1, "name": "Alice"},
                  {"id": 2, "name": "Bob"}
                ]
              }

ザックリいえば、どんなURLにどんなリクエストを送ればどんなレスポンスが返ってくるか？を定義しているものがRAMLだと理解できればOK。他のプログラミング言語のように複雑な構文や条件分岐等も基本的にはなく、あくまでもドキュメンテーションとしての役割を果たしているものだと言えます。

上記の基本的な構造を理解しておくことで、あとは必要に応じて少しずつ拡張していけばOKです。

より実践的なRAMLの書き方

ここからはより実践的に、APIの機能を拡張しより詳細なAPI仕様を作成する方法をご説明していきます。

1. クエリパラメータの定義

APIエンドポイントにクエリパラメータを追加してユーザーが様々な形のリクエストを送れるようにすることもできます。例えば、ユーザーリストを取得する際に、年齢や職業でフィルタリングできるようにできたら便利です。

/users:
  get:
    description: Returns a list of users filtered by age and job
    queryParameters:
      age:
        description: Filter by age
        type: integer
        required: false
      job:
        description: Filter by job
        type: string
        required: false
    responses:
      200:
        body:
          application/json:
            example: |
              {
                "users": [
                  {"id": 1, "name": "Alice", "age": 30, "job": "Engineer"},
                  {"id": 2, "name": "Bob", "age": 25, "job": "Designer"}
                ]
              }

クエリパラメータは、URLの一部としてデータを送る方法でWebサーバーに特定の情報を求める際に使われるのが一般的。クエリパラメータはURLの末尾に「？」記号の後に続けて記入され、キー（名前）と値の組み合わせで指定されます。複数のパラメータを送る場合は、「&」記号で区切ります。

例えば、年齢と職業でユーザー情報を絞り込む場合は以下のようなURLになります。

Example Domain

example.com

この例では、age=25 と job=developer がクエリパラメータ。こうすることで年齢が25歳で職業が開発者（developer）のユーザー情報をWebサーバーにリクエストすることができるようになります。

2. ヘッダーとURIパラメータの追加

ヘッダーを使ってリクエストやレスポンスに追加の情報を含めることもできます。また、URIパラメータを利用して特定のリソースにアクセスする際の動的なパスを指定するようなことも可能です。

/users/{userId}:
  get:
    description: Returns a specific user by their ID
    uriParameters:
      userId:
        description: The user's ID
        type: integer
    headers:
      X-Request-ID:
        description: A unique identifier for the request
        type: string
    responses:
      200:
        body:
          application/json:
            example: |
              {
                "id": 1,
                "name": "Alice",
                "age": 30,
                "job": "Engineer"
              }

3. レスポンスとエラーハンドリングの定義

APIのレスポンスを詳細に定義することでエラー発生時のハンドリングを行うことも可能です。

/users/{userId}:
  get:
    responses:
      200:
        body:
          application/json:
            example: |
              {"id": 1, "name": "Alice", "age": 30, "job": "Engineer"}
      404:
        body:
          application/json:
            example: |
              {"error": "User not found"}

↑の例では、/users/{userId} エンドポイントに対するGETリクエストで、ユーザーIDに基づいてユーザー情報を取得する操作を定義。レスポンスとして成功時（200）はユーザーの情報を、失敗時（404）はエラーメッセージを返すことが示されています。

このようにレスポンスとエラーハンドリングを明確にすることで、APIの使用者はどんな結果を期待できるか、そして何か問題が発生したときにはどのように対応すればよいかを正確に理解することができるようになります。

例えば、食べログのサイトではGoogleマップでお店の場所を表示させていますが、これは「GoogleマップのAPI」が利用されています。

緯度と経緯をGoogleマップさんに伝えれば、Googleマップの機能を利用して（APIを利用して）地図を表示してくれるという便利な仕組みを実現できるのがAPIです。

このページでは、IT初心者向けにそもそもAPIって何？APIとWebAPIの違いって何？APIを使うと何がうれしいの？という素朴な疑問にお答えしていきます。

クラウド技術が発展する現代において理解必須の超・重要知識です。是非最後までご覧ください。

APIとは？

APIとは、 APIとは Application Programming Interface の略で、アプリケーションやOSの機能の一部を他のアプリケーションから利用できるようにした窓口。「えーぴーあい」と発音します。

例えば、LINEにはメッセージを送ったりプロフィールを閲覧したりする機能が備えられています。普通はこれらの機能をLINEのアプリを開いて利用します。

ですが、例えばLINE以外のアプリケーションから「LINEの機能を使って」メッセージを送ったりしたい場合もあります。その際に利用するのがAPIです。

APIを利用することで、他のソフトウェアからLINEの機能でメッセージ送信機能や、プロフィール画像の取得といった機能を使えるようになります。

他のソフトウェア・アプリケーションから、機能の一部を呼び出して利用する際の窓口。これがAPIの仕組みです。

APIのメリット

APIを利用するメリットは主に以下の４点。１つひとつ解説します。

APIのメリット１：開発コストの削減

APIを利用することで開発コストの削減を行うことができます。

例えば、自社のサイトに会員登録の機能を作成する場合。会員登録の機能を行うには、ユーザ情報の管理機能（ID・パスワード管理）や、ログイン・認証機能を１から実装していく必要がありますが、APIを利用しSNSのアカウントでログインさせるようにすることで、１から実装する必要がある機能を最小限に抑えることが可能になります。

既に世の中に存在している様々な機能をうまく取り入れることができるようになる！というのがAPIを利用する大きなメリットの１つです。

APIのメリット２：利便性の向上

APIを利用することで、開発コストを削減しつつ、同時に利便性の向上にもつながります。

先のSNSアカウントを利用した会員登録機能を例に考えてみると、ユーザ側からすると同じ会員情報を１から登録するという手間が省けます。APIを利用することで、システム間でのデータ重複や不整合をなくすことができるため、システム不具合（バグ）を最小限にできるという特性を持ちます。

ユーザにとってみれば、サイトごとにユーザ登録をする必要が無くなり、１か所で作ったユーザ情報を様々なサイトでも使いまわせるようになり大変便利になります。

APIのメリット３：セキュリティの向上

会員情報など、ユーザの個人情報を扱う場合などは特にセキュリティの強化が必要となります。昨今、この個人情報を悪用した例が日々世間を賑わせているのはご存じの通りです。

APIを利用することで、このセキュリティの担保を外部に転嫁することが可能となります。自社で１から機能を実装するより、世界的に権威あるシステムの機能を拝借するほうが比較的楽にセキュリティを向上させることが可能になるのです。

Web APIとは？（APIとの違いは？）

ここまで紹介したGoogleマップのAPI、LINEのAPIはどれもWeb APIに分類されます。

Web APIとは、Web上で（インターネットを介して）利用するAPIのこと。HTTP/HTTPS通信でやりとりを行っており、Facebook API、Twitter API、Google APIなどが有名です。これらは、Web上にAPIの窓口が設けられており、指定のURLにリクエストを送ることでFacebookやTwitterの機能を利用します。

現代ではこのようにWeb上に公開されているAPIが一般的であるため、単にAPIと言うと「Web API」を指すことがほとんどです。

ですが、本来の意味としてはAPIとは、あくまでもアプリケーションやOSの機能の一部を他のアプリケーションから利用できるようにした窓口という意味なので、包括関係は以下の通りです。

例えば、Windowsの機能を利用できる「Windows API」などはWeb APIではありません。これはインターネットを通してAPIを利用するわけではないためです。

そのうえで、昨今APIと言えばWeb上に窓口が設けられているものがほとんどになっているため、APIと言えばWeb APIのことを指すことが一般的です。

ただし、本来の意味としてはプログラムとプログラムを接続する仕組みがAPIであり、この点の理解が不足しているとWindowsAPIなどの、非Web APIの話についていけなくなるため注意が必要です。

ITを１から学びたい方は

システムエンジニアを目指す方や、IT知識を１から身につけたい方は以下のページをご覧ください。

正直どこから学び始めればよいかわからない。どのように勉強していけば、エンジニアとしてのスキルが磨けるか？が分からない・・・という方は必見です。

システムエンジニア向けに「できるエンジニア」になる方法を１から解説しておりますので、是非ご覧ください。

＃無料で読めるようにしてあります。累計12万人が参考にしていただきました！

1人前のシステムエンジニア(SE)になるために勉強した５つのこと

本ページでは、１人前のシステムエンジニアになるために学んだこと・読んだ本・勉強したプログラミング言語を現役のエンジニアが１から紹介しています。「正直何を勉強したらよいかわからない」という疑問をお持ちの方は特に必見です。

it-biz.online

2021.07.29

インターネット上からの不正なアクセスを防ぐことは勿論、内部からの許可されていない通信をシャットダウンする役割も同時に担うことが一般的です。

ファイアウォールは、許可された通信と不正な通信を区別するために特定のルールやポリシーを必要とします。これらのルールは、組織や個人のセキュリティ要件に応じてカスタマイズすることが可能で、特定のIPアドレス、ポート番号、プロトコル、アプリケーションなどに対するアクセス制御を行うことができます。

またファイアウォールと一言にいっても、その仕組みや種類によって多種多様です。そのため、結局ファイアウォールの実体が良くわからない人が多いのだと思います。

このページではファイアウォールの基本知識を網羅的にわかりやすく解説します。

ネットワークエンジニアを目指す方であれば知らないと恥ずかしい超・基本知識の１つです。是非最後までご覧ください。

ファイアウォールとは？

ファイアウォールとは、コンピュータネットワークのセキュリティを高めるために設計されたシステムであり、外部からの不正アクセスやウイルス、マルウェアなどの脅威からネットワーク内のデバイスを保護する役割を担います。

ファイアウォールは、コンピュータネットワークの歴史と発展に伴ってその技術も進化してきました。

簡単にファイアウォールの歴史と発展を整理してみました↓

ご覧のように、ファイアウォールと一言で言っても発展とともに様々な種類があることが分かるかと思います。

が、基本的な思想はどの時代も同じで「危険にさらすのは、特定のサーバやルータに限定する」ということ。つまり、セキュリティ的に外部からの脅威にさらされてOKなものとそうでないものを区別し、外部からの脅威にさらされるサーバやルータに対して集中的にセキュリティを強化するという考え方です。

ここからは具体的にファイアウォールの仕組みを見ていきながら、より詳細にファイアウォールについてご説明します。

パケットフィルタリング型ファイアウォール

初期のファイアウォールは「パケットフィルタリング型」と呼ばれるタイプのファイアウォールです。

パケットフィルタリング型ファイアウォールは、ネットワーク上で送受信されるデータパケットを検査し、設定されたルールに基づいてパケットを許可または拒否します。

主にIPアドレス、ポート番号、およびプロトコル（TCP、UDP、ICMPなど）を基に、送信元と宛先に対してアクセス制御を行います。

参考　通信プロトコルとは？ （ TCP / UDP / ICMP ）

パケットフィルタリング型ファイアウォールの設定は、主にアクセス制御リスト（ACL）と呼ばれるルールセットに基づいて行われます。例えば、ある企業の内部ネットワークがあり、その企業は次のようなセキュリティポリシーを適用したいとします。

この場合、次のようなパケットフィルタリング型ファイアウォールの設定が考えられます。

例えばNo.4に着目すると、インターネット側から企業内部へのRDP（リモートデスクトップ接続）の通信を拒否していることが分かります。つまり、この企業では外部からリモートデスクトップを一切拒否することによってRDP関連の脅威からネットワークを守っていると言えます。

上記の設定はあくまで一例ですが、このような設定を細かく行うことで各個人・各企業で独自のセキュリティ網を構築することが可能だということがわかるでしょう。

【特徴と限界】パケットフィルタリング型ファイアウォール

パケットフィルタリング型ファイアウォールの特徴と限界を整理すると以下の通りになります。

要約すると、シンプルで分かりやすい。しかし、その分複雑な通信制御ができないというのがパケットフィルタリング型ファイアウォールのポイントです。

例えば、パケットフィルタリング型ファイアウォールでは、特定のIPアドレスからの通信のみを許可する設定を行ったとしても、もしIPアドレス自体が偽装されその中身のデータにウイルスが潜んでいれば、この脅威を防ぐことはできないのです。

他にもパケットフィルタリング型のファイアウォールでは防げない脅威が徐々に表れてくると、それを克服するために後続のファイアウォール技術（ステートフルインスペクション、アプリケーションレベル、次世代ファイアウォール）が開発されることになります。

ここからは、次のステップ：ステートフルインスペクション型ファイアウォールについて解説します。

ステートフルインスペクション型ファイアウォール

ステートフルインスペクション型ファイアウォールは、パケットフィルタリング型ファイアウォールの限界を克服するために開発された技術です。

主な特徴は次のとおり。

ポイントは、ステートとセッションです。

実際のステートフルインスペクション型ファイアウォールの設定内容は、以下のような要素を含むことが一般的です。

要するに、パケットフィルタリング型ファイアウォールの特徴に加えて、その接続状態（新規？継続？）の判定＋セッションのタイムアウトの制御を行うのがステートフルインスペクション型ファイアウォール。

これに加えて、行われた通信の記録（ロギング）やアラート発生時のメール通知などの機能を備えていることが特徴です。

ただし、ステートフルインスペクション型ファイアウォールにも限界があります。それが、通信の中身までを確認することができないという点です。通信の中身まで確認することができない→例えばメールに添付されたウイルスファイルなどを検知することができません。

いくらメール送受信にリスクがあるからと言えど、メールの送受信を不許可にすることは現実的ではありませんよね。そこで新たに生み出されたのがアプリケーションレベルファイアウォールです。

アプリケーションレベルファイアウォール

アプリケーションレベルファイアウォール（またはプロキシベースファイアウォール）は、ネットワーク層やトランスポート層でのフィルタリングに加えて、アプリケーション層でのフィルタリングも行うファイアウォールのタイプです。

参考　OSI参照モデル（ネットワーク層/トランスポート層/アプリケーション層）

アプリケーションレベルファイアウォールは、特定のアプリケーションやプロトコルに対する深い検査（ディープパケットインスペクション）を行い、通信の内容や振る舞いに基づいてアクセス制御を行うことが可能です。

具体的にアプリケーションレベルファイアウォールの特徴を示すと以下の通りです。

1. アプリケーション層の監視
   • アプリケーションレベルファイアウォールは、HTTP/HTTPS、FTPなどのアプリケーションプロトコルのトラフィックを解析。
   • パケットの内容を深く検査し、特定のアプリケーションやサービスに関連するトラフィックを特定可能。
2. 詳細なコンテンツフィルタリング
   • 不正なコマンド、マルウェア、スパムなど、不正なコンテンツを含むパケットを特定し、ブロック。
   • アプリケーションの特定の機能や動作を許可または拒否する詳細なポリシーを設定可能
3. セキュリティの強化
   • アプリケーション層の攻撃、例えばSQLインジェクションやクロスサイトスクリプティング（XSS）などに対する保護を提供。
   • ユーザーの認証とアクセス制御を強化し、アプリケーションへの不正アクセスを防ぐ。
4. ログと監査
   • トランザクションレベルでの詳細なログ記録を提供し、セキュリティ監査や法的要件に対応。
   • 通過するトラフィックの詳細な分析とレポーティング機能を備える。

アプリケーションレベルファイアウォールは、特にアプリケーション層での攻撃に対して強力な保護を提供し、企業のセキュリティインフラストラクチャの重要な部分となります。しかし、その設定と管理には高度な専門知識と注意が必要になります。非常に簡単ではありますが、アプリケーションレベルファイアウォールではどのような設定が行われるのかを例示しておきます。

1. Webアプリケーションの保護
   • 目的: Webサーバーへの攻撃を防ぐ。
   • 設定:
     • HTTP/HTTPSトラフィックのみを許可。
     • SQLインジェクションやXSS攻撃のパターンに基づくフィルタリングを有効化。
     • 不正な入力値や不審なURLアクセスをブロック。
2. メールサーバーの保護
   • 目的: スパムやフィッシング攻撃からメールサーバーを守る。
   • 設定:
     • SMTP、IMAP、POP3プロトコルのトラフィックのみを許可。
     • メールコンテンツ内の不審なリンクや添付ファイルをスキャンし、ブロック。
3. FTPサービスの制御
   • 目的: FTPを通じた不正なファイル転送を防ぐ。
   • 設定:
     • FTPトラフィックのみを許可。
     • 不正なファイル形式や異常なファイルサイズの転送を検知し、ブロック。
4. APIエンドポイントのセキュリティ
   • 目的: 外部APIエンドポイントへの不正アクセスを防ぐ。
   • 設定:
     • 特定のAPIエンドポイントへのアクセスを特定のIPアドレス範囲に限定。
     • APIリクエストのレートリミットを設定。

参考　APIとは？

↑の設定例は、アプリケーションレベルファイアウォールの適用範囲と機能を示していますが、実際の設定は、会社や個人における特定のニーズとセキュリティポリシーに合わせて調整されます。。

ファイアウォールの種類

ここまででファイアウォールの仕組みをいくつかのタイプに分類して解説してきました。

最後にこの章ではファイアウォールのいくつかの製品をご紹介します。

ファイアウォールには主にハードウェアファイアウォール、ソフトウェアファイアウォール、クラウドベースのファイアウォールの3つの種類があります。

ハードウェアファイアウォールは専用機器で、高速で安定した処理能力が特徴ですが、初期投資が高いことが多いです（例: Cisco ASA シリーズ）。

ソフトウェアファイアウォールはコンピュータ上で動作するプログラムで、低価格または無料で利用できることが多いものの、コンピュータのリソースに依存するため処理速度に影響がある場合があります（例: Windowsファイアウォール、ZoneAlarm）。

クラウドベースのファイアウォールはクラウドサービス上で提供され、スケーラビリティが高くリモート管理が可能ですが、サブスクリプション料金がかかります（例: Zscaler、Barracuda CloudGen Firewall）。

それぞれの種類には独自の特徴と違いがあり、組織やネットワーク環境に合わせて最適なファイアウォールを選択することが重要です。

ネットワークエンジニアを目指したい方は

TCPをはじめとして、ネットワークの基礎を１から学びたい方はこちらの書籍を購入してがっつり学びましょう！

さくっと手軽に読める内容ではないのですが、ネットワークエンジニア全員が必ず読破している本と言っても過言ではありません。是非この機会にチャレンジしてみてみましょう。

マスタリングTCP/IP　入門編（第6版）

インターネットのプロトコルTCP/IP入門書の決定版!

Amazon

楽天

また、ファイアウォールを学んだあなたは、ネットワークの基本概念に興味を持っているかもしれません。

これを機に、ネットワーク全体についてもっと学びませんか？以下の記事では、初心者でも理解できるようにネットワークの世界を１からわかりやすく解説しています。さらなる知識を手に入れて、ネットワークのプロフェッショナルへの道を歩み始めましょう！こちらの記事をチェックしてみてください。

ゼロから学ぶネットワーク入門：50記事で完全解説

【ネットワーク】初心者でも安心して学べるよう、基礎から応用まで段階的に解説。50記事で構成されたこのシリーズを読めば、あなたもネットワークのエキスパートへ一歩近づくことができます。今すぐ始めて、未来のネットワーク世界を切り開こう！

it-biz.online

2024.01.18

参考　SSH(Secure Shell)とは？

vpsを契約したばかりの人や、ネットワーク初心者には少し難しいかもしれませんが、確認方法（修正方法：コマンド付き）をわかりやすく解説します。

SSH接続確認１：ネットワークの疎通確認（ping）

ネットワークの問題 確認方法: ping コマンドを使って、対象のサーバに到達可能か確認してください。

ping <サーバのIPアドレス>

参考　pingコマンドとは？（ICMPとは？）

もし疎通ができていれば以下のような結果になります。

C:\Users>ping 192.168.100.1

192.168.100.1 に ping を送信しています 32 バイトのデータ:
192.168.100.1 からの応答: バイト数 =32 時間 =18ms TTL=51
192.168.100.1 からの応答: バイト数 =32 時間 =31ms TTL=51
192.168.100.1 からの応答: バイト数 =32 時間 =31ms TTL=51
192.168.100.1 からの応答: バイト数 =32 時間 =37ms TTL=51

192.168.100.1 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 18ms、最大 = 37ms、平均 = 29ms

疎通に失敗していれば以下のような結果になります。

C:\Users>ping 192.168.100.1

192.168.100.1 に ping を送信しています 32 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。

192.168.100.1 の ping 統計:
    パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、

疎通に成功した方は次へ。そうでない方は以下のポイントをチェックしてください。

参考　DNS / IPアドレス / ファイアウォール

SSH接続確認２：SSHサーバの起動確認

SSHサーバ（SSHD）が起動しているかどうかを確認してください。

サーバに直接アクセスできる場合、以下のコマンドを実行してSSHサービスの状態を確認してください。

sudo systemctl status sshd

起動している場合は以下が表示されます。４行目の「active (running)」を確認。

$ sudo systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2023-03-28 12:30:57 PDT; 2 days ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1080 (sshd)
   Memory: 3.2M
   CGroup: /system.slice/sshd.service
           └─1080 /usr/bin/sshd -D -e

Mar 28 12:30:57 localhost.localdomain systemd[1]: Starting OpenSSH server daemon...
Mar 28 12:30:57 localhost.localdomain sshd[1080]: Server listening on 0.0.0.0 port 22.
Mar 28 12:30:57 localhost.localdomain sshd[1080]: Server listening on :: port 22.
Mar 28 12:30:57 localhost.localdomain systemd[1]: Started OpenSSH server daemon.

起動していない場合は以下が表示されます。４行目の「inactive (dead)」を確認してください。

$ sudo systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:sshd(8)
           man:sshd_config(5)

対処方法→以下のコマンドを実行しSSHDを起動します。

sudo systemctl start sshd

SSH接続確認３：SSHポートの確認

SSHのポート番号が変更されている場合にSSH接続が失敗します。

参考　ポート番号とは？

/etc/ssh/sshd_config ファイルを開いて、Port の設定を確認してください。

# cat /etc/ssh/sshd_config | grep "^Port"
Port 10022

上記の例では、sshd_configファイルの中で、行の先頭に"Port"という文字列が含まれる行を検索しています。上記の検索結果は、SSHのポート番号として「10022」が利用されていることが分かります。

ポートが変更されている場合、SSH接続時に正しいポート番号を指定してください。

ssh -p <ポート番号> <ユーザ名>@<サーバのIPアドレス>

SSH(Secure Shell)とは？初心者向けにわかりやすく３分で解説

【ネットワーク】SSH(Secure Shell)を3分で解説！初心者向けにわかりやすくSSHの基本概念や利用方法を紹介。安全なリモートアクセスを簡単に始められるようになります。

it-biz.online

2024.01.10

SSH接続確認４：sshd_configファイルの確認

sshd_configファイルは、SSHサーバー（sshd）の設定ファイルであり、SSHの動作や接続に関する様々な設定を変更できます。

sshd_configファイルの確認方法
sshd_configファイルは通常、/etc/ssh/sshd_configパスに保存されています。以下のコマンドで確認できます。

# cat /etc/ssh/sshd_config

特に以下の太字項目が想定通りであるかどうか？を確認してください。

SSH接続確認５：認証情報の確認

それでもssh接続ができない場合は接続しようとしているユーザ名とパスワード、または鍵ペアが正しいかどうか確認してください。

案外このポイントで詰まっている場合も多いので改めて確認しましょう。

マスタリングTCP/IP　入門編（第6版）

インターネットのプロトコルTCP/IP入門書の決定版!

Amazon

楽天

SSH接続に苦戦したあなたはネットワークの知識不足を痛感したかもしれません。

これを機に、ネットワーク全体についてもっと学びませんか？以下の記事では、初心者でも理解できるようにネットワークの世界を１からわかりやすく解説しています。さらなる知識を手に入れて、ネットワークのプロフェッショナルへの道を歩み始めましょう！こちらの記事をチェックしてみてください。

ゼロから学ぶネットワーク入門：50記事で完全解説

【ネットワーク】初心者でも安心して学べるよう、基礎から応用まで段階的に解説。50記事で構成されたこのシリーズを読めば、あなたもネットワークのエキスパートへ一歩近づくことができます。今すぐ始めて、未来のネットワーク世界を切り開こう！

it-biz.online

2024.01.18

現代のネットワーク環境ではさまざまなデバイスやアプリケーションが常に相互に通信していますが、VLANを構築することで、①ネットワーク内の通信デバイスを効率的に管理し、②必要な部分だけを隔離・制御することで、ネットワーク全体のパフォーマンスを最適化することができます。

VLANはネットワーク内のトラフィックを制御し、セキュリティを強化するための鍵となる技術。特に大規模な組織や、セキュリティが重要な環境では、VLANを活用することで、ネットワークの運用をより柔軟にかつ安全に行うことができます。

この記事ではVLANの基本的な概念から、VLANの構築方法、VLANの利点、そして実際の使用例に至るまでを詳しく解説していきます。IT初心者の方でも理解しやすいように、各セクションで重要なポイントを明確に図解しつつ詳細に解説いたします。

VLANとは？わかりやすく

VLAN：Virtual Local Area Network（バーチャル・ローカル・エリア・ネットワーク）は、物理的なネットワークの構造に影響されず、複数の独立したネットワークを仮想的に構築する技術。

異なる場所にあるデバイスを同じネットワークに属させたり、同じ場所にあるデバイスを異なるネットワークに割り当てたりすることができます。

例えば、会社の経理部門と営業部門は物理的には同じフロアにあるかもしれませんが、VLANを使用することで、それぞれが別々のネットワークに属するように設定することができます。

VLANと物理的LANの違い

物理的なLAN（Local Area Network）は、ケーブルやスイッチなどの物理的なハードウェアによって接続されたネットワークです。

参考　LAN（Local Area Network）とは？

一方で、VLANは物理的な接続に依存せず、ソフトウェアを用いてネットワークを仮想的に分割するという点が重要なポイント。つまり、物理的なデバイスの位置や配線の接続に縛られることなく、柔軟なネットワーク設計が可能になるという点を押さえておきましょう。

VLANの動作原理

では、具体的にどのように仮想的なネットワーク（VLAN）が構築され、どのように動作するのか？を見ていきましょう。ここでは簡単なネットワーク構成を例に、１つのネットワークを複数の仮想的なネットワークに分割する方法を順を追ってご説明していきます。

VLANの設定/構築方法

まずVLANはネットワーク内のスイッチに設定されます。スイッチとはOSI参照モデルの第２層：データリンク層で動作するネットワーク機器で、流れてきたデータの宛先MACアドレスを参照し、適切な機器へデータを転送する役割を担います。

参考　スイッチとは？ / MACアドレスとは？

したがって、ネットワーク管理者はスイッチ上で複数のVLANを設定していくことになります。具体的には各VLANに独自のID（たとえばVLAN 10、VLAN 20など）を割り当てることで、まずはVLANの箱・枠を作成します。

Ciscoスイッチを用いる場合、以下のようなコマンドを実行することでVLANの枠を設定します。

使用するスイッチ: Ciscoスイッチ（Catalystシリーズなど）
設定するVLAN: VLAN 10（経理部門用）、VLAN 20（営業部門用）
----設定コマンド例----

conf t
vlan 10
name Accounting
vlan 20
name Sales
end

次にスイッチ上の各ポートを特定のVLANに割り当てます。ポートとは実際にデバイスを接続する口のことで、LANケーブルを利用する際にPCに接続する接続口をイメージいただければOKです。

ここで、ポート1～4をVLAN 10に、ポート5～8をVLAN 20に割り当てます。そうすることで、ポート1~4に接続されているネットワーク機器はVLAN 10に接続していることになります。（ポート5~8は、VLAN 20に接続。）

ポート1～4をVLAN 10（経理部門）に、
ポート5～8をVLAN 20（営業部門）に割り当て。
----設定コマンド例----

conf t
interface range fa0/1 - 4
switchport mode access
switchport access vlan 10
exit
interface range fa0/5 - 8
switchport mode access
switchport access vlan 20
end

VLAN設定後の動作/通信制御

上記の設定を行った後で、VLAN内のデータ転送がそれぞれどのように行われるのかを見ていきます。

ポイント　VLAN内のデータ転送の原則

• VLAN 10（経理部門用）とVLAN 20（営業部門用）が設定されている。→つまり、スイッチ上の各ポートが特定のVLANに割り当てられ、それぞれ独立したネットワークとして機能している状態。
• このときVLAN 10に割り当てられたポート（例：ポート1～4）に接続されたデバイスは、VLAN 10内でのみ通信が可能になります。つまり、これらのデバイスからのデータはVLAN 10内の他のデバイスにのみ送信され、VLAN 20のデバイスには届きません。

１つのネットワークを、VLANという仮想的なネットワークに分けたことで、異なるVLANに振り分けられた通信機器は相互に通信ができなくなるという点がポイント。

ネットワークが異なる（IPアドレスのネットワーク部が異なる）場合はルーターやL3スイッチを設置しルーティングしないとネットワーク間での通信が行えないのと同じ状態です。

ではなぜVLAN間での直接通信が制限されるのか？ここから、VLANの詳しい動作原理についてご説明します。

VLANID/VLANタグ

VLANに割り当てられたポートから送信されるフレームには、VLAN IDを示すタグ（VLANタグ）が付与されます。このタグは、IEEE 802.1Q標準で定義された世界標準のフォーマットを持ちます。（この章の最後でフレームのサンプルフォーマットを提示します。）

VLANタグにはVLAN IDが含まれており、これによりスイッチはフレームがどのVLANに属するかを識別することができます。

VLAN ID が10であればVLAN 10から送信されたフレームなんだな・・・。VLAN ID が20であればVLAN 20から送信されたフレームなんだな・・・と判断しているということです。

スイッチはVLANタグを用いてフレームを適切なVLAN内のポートにのみ転送します。異なるVLAN IDを持つフレームは、それぞれ異なるVLANに属するため、互いに直接転送されません。　→このプロセスにより、異なるVLANは論理的に分離され、それぞれが独立したネットワークセグメントとして機能する、という仕組みです。

先ほども触れたように異なるVLAN間で相互に通信を行うためには、ルーターまたはレイヤー3スイッチが必要です。これらのデバイスは、異なるVLANからのフレームを受け取り、IPアドレスに基づいて適切なVLANにルーティングします。

参考　ルーティングとは？

VLAN設定により、フレームにVLANタグが付与され、それに基づいてスイッチはVLAN間でのフレームの転送を制御します。これにより、VLANは論理的に分離された独立したネットワークセグメントとして機能。

VLAN間での通信を行うためには、ルーターやレイヤー3スイッチによる経路制御が不可欠です。これらのデバイスはVLAN間でのデータフローを管理し、ネットワークのセキュリティと効率を保つ。

↑を十分に理解しておきましょう。

AA AA AA AA AA AA AA AB 00 1A 2B 3C 4D 5E 5E 4D 3C 2B 1A 00 81 00 00 0A 08 00 46 00 ... 1A 2B 3C 4D

ここまで説明したVLANはｍVLANの中でも特に「スタティックVLAN」と呼ばれるタイプのものを例にご紹介してきました。（VLANの基本原理が理解しやすいため）

実際には大規模なネットワークになればなるほどダイナミックVLANと呼ばれる「スイッチ上でVLANの設定を自動で行う」方法もありますので、詳しく知りたい方は合わせて以下の記事もご覧ください。

スタティックVLANとダイナミックVLAN：違いと動作原理を３分で解説

【初心者向けに】スタティックVLANとダイナミックVLANの基本原理、設定方法、およびそれぞれの利点と制約について詳細に解説します。VLANの動作原理を理解し、適切なネットワーク設計と管理を行うための必読ガイド。

it-biz.online

2024.01.29

VLANの利点/メリット

これまでも何度かご説明してきた通り、VLANはネットワークを仮想的に細分化するため、セキュリティを強化する効果があります。また同時に、細分化によるパフォーマンスの向上やコスト削減効果、柔軟なネットワーク設計を可能にするなどのメリットがあります。

結果、大きな企業や組織は、物理的な制約に縛られることなく、効率的かつ安全なネットワーク環境を構築することを目的としてVLANを構築することが一般的になっています。

ポイント　VLANのメリット

1. セキュリティの強化
   • VLANを使用することで、ネットワーク内で異なるグループや部門を論理的に分離することが可能。これにより敏感なデータを扱う部門を他の部門から隔離するなどして、不正アクセスや内部からの脅威を軽減することができる。
2. ネットワークのパフォーマンス向上
   • VLANはネットワークトラフィックを適切に分割し、ブロードキャストドメインを小さくする。結果→ネットワーク上の不要なトラフィックが減少し、全体的なパフォーマンスが向上する。
3. 効率的なトラフィック管理
   • VLANにより、ネットワークトラフィックを効率的に制御することができるので、特定のグループ間でのデータフローを最適化できる。
4. コスト削減
   • 物理的なネットワークの再構築や配線を追加したりすることをせずに、ネットワークの再設計が可能。→将来的な新部門の追加やオフィス拡張などに伴うコストを削減することができる。
5. 柔軟なネットワーク設計
   • VLANはネットワークの設計に柔軟性をもたらす。物理的な場所に依存せずに、異なる部門やグループを簡単に分離・統合が可能。
6. 物理的な制約からの解放
   • VLANは物理的な場所に依存しないため、異なる場所にいるユーザーを同じネットワークに簡単に組み込むことができる。これにより、リモートワークや分散したオフィス環境でのネットワーク管理が容易になる。
7. 障害の局所化
   • VLANはネットワークの問題や障害を局所化し、他のVLANに影響を与えることなく問題を特定し、解決できる。

VLAN実装の課題

VLANの実装は多くの利点をもたらしますが、同時にこれらの課題に対処するためには適切な計画、設計、および継続的な管理が必要になります。

特に大規模なネットワークでは、これらの課題に対する慎重なアプローチが求められます。

以下の課題（よくある躓きポイント）を押さえ、適切なVLAN管理が行えるようにすることが重要です。

1. 複雑性の増加
   • VLANの設定と管理は、特に大規模なネットワークでは複雑になりがち。異なるVLAN間での適切な通信ルールを設定し、管理するには、専門的な知識と注意深い計画が必要。
2. 互換性の問題
   • 異なるベンダーの機器間でのVLAN設定の互換性は常に保証されるわけではない。特に、異なるベンダーのスイッチやルーターを組み合わせて使用する場合、互換性の問題が生じる可能性がある。
3. セキュリティの課題
   • VLANはセキュリティを強化する一方で、適切に設定されていない場合はセキュリティリスクを生じさせる可能性もある。例えば、VLANホッピング攻撃（VLANのセキュリティをバイパスして他のVLANにアクセスする手法）などの考慮が必要。
4. スケーラビリティの制限
   • VLAN IDは有限（標準的なVLANでは4096までのID）。大規模なネットワークでは、VLANの数が増えるとIDの割り当てが問題となることもある。
5. パフォーマンスへの影響
   • 不適切なVLAN設計や過度なVLANの使用は、ネットワークのパフォーマンスに悪影響を及ぼす可能性があります。特に、ルーターを介したVLAN間通信は、追加の遅延を引き起こすことがあるため要注意。
6. 管理の負担
   • VLANの設定変更、管理、トラブルシューティングは、時間と労力を要する作業。特にネットワークが拡大するにつれて、これらの作業はより複雑になる。

まとめ　VLAN（Virtual Local Area Network）とは？

• 論理的なネットワークセグメント
  • VLANは物理的な位置に関わらず、ネットワークを複数の仮想的なネットワーク（＝セグメント）に分割する仕組み。
• セキュリティと効率の向上
  • 異なるグループや部門を分離→ネットワークトラフィックとセキュリティを適切に管理することができる。
• フレキシブルなネットワーク管理
  • 物理的なネットワーク構造に縛られず、簡単にネットワークを再構築できる。
• VLANタグ付け
  • フレームにVLAN IDを付けることで、データが属するVLANを識別する。

ネットワーク学習の決定版（ネットワークエンジニアを目指すなら必見！）

マスタリングTCP/IP　入門編（第6版）

インターネットのプロトコルTCP/IP入門書の決定版!

Amazon

楽天

↑ページ数が多く誰でも手軽に読める内容ではありませんが、ネットワークエンジニアであれば、ほぼ全員が一度は読んだことがある超・有料書籍。是非一度読破しておきたい１冊のご紹介です。

読者特典＞　0から学ぶネットワーク入門