実習課題

DC/クラウド 冗長性

インターネットユーザの爆発的な増加により、電子商取引サイトやネット証券等、インターネット上でリアルなお金をやり取りする企業が出現した。これら企業にとってはサービス断は機会損失であり、１分のサービス断が膨大な損失をもたらす事もある。

ところで、インターネットでサービスを提供するシステムにおいては、対象とするユーザ数は不特定であり、かつそのサービスには世界中からアクセスされる可能性がある、という特徴がある。したがって、システムには、ユーザ数の増加に対して無停止で処理能力が増強できること、24時間365日無停止でサービスを継続的に提供可能であること、の両者が必要になる。

実際にある時点から、インターネット上でのサービスは24時間365日稼働するのが常識となっていった。当然、それに携わるエンジニアには、無停止でサービスを提供することが可能なシステムの構築・運用を実現できる技術が求められるようになっている。

本項目では、サービス提供能力が増加・縮小可能で、かつ、24時間365日サービスを提供可能とするシステムを構築できるようになるために、以下の2点について習得する。

1. サーバーロードバランサを用いて、サービス提供能力を弾力的に増強・縮小可能とするスケールアウト型のシステム構成。
2. ネットワークを中心にシステムを構成する機器を複数台用いた冗長構成とすることで、サービスを継続的に提供するシステム構成。

DC/クラウド 冗長性 トラブルシューティング

「冗長構成ネットワークの構築」という課題項目で説明したとおり、インターネット上にサービスを提供するシステムは24時間365日無停止で継続的にサービスを提供することが求められる。ところが、理屈の上では無停止で稼働するはずのネットワークであっても、適切に運用しなければサービス停止を招く。

エンジニアとしてこのような事態を起こさないために、冗長化の理屈を理解した上で、適切な手順でメンテナンス対象の機器を稼働系から切り離す、対象機器を交換する、ファームウェアアップデート等のメンテナンスを実施する、さらに、適切にメンテナンス対象機器を稼働系に組み込む、といった一連の作業を正しく行える技術を習得している必要がある。

本項目では「冗長構成ネットワークの構築」で構築したシステムを対象として、機器の交換・ファームウェアのアップデートを無停止で実施する実習を通して、無停止でのサービス提供について理解を深めるとともに操作に習熟する。

DC/クラウド 仮想化 冗長性

クラウドは、いまや利便性と拡張性が高く、ITサービスを提供するための必要リソースが揃ったあたり前のコンピューティング環境となった。その結果、ITサービスを開発・運用するエンジニアには、クラウドの利用技術に熟達していることが望まれるようになってきている。一方で、あまりにもあたり前のコンピューティング環境となってきたために、クラウドそれ自身が実際にどのような形で構築されているのか、ということを理解する必要性は徐々に減ってきている。

ところが、開発中、あるいは、提供中のITサービスに問題が生じたとき、その解決のためにはクラウドの仕組みに対する深い理解が必要となることがある。さらにまた、利用しているクラウドサービスの性能を最大限に活かしているか、利用しているクラウド領域の拡張／縮退が必要かどうかなどの判断も、深い理解がないと難しい。また、クラウドの実装においては、サーバとネットワークの仮想化技術を抜きには語れないが、その技術の実態と応用の仕組みに触れる機会は多くはない。

上記を踏まえて、本項目ではクラウド（IaaSに主眼）を自前で構築することによって、クラウドアーキテクチャの理解を深め、仮想化技術の利用と応用を実践することを目的とする。その上で、安定的なリソース管理の重要性を理解し、クラウドの運用技術についても習得することを目指す。

DC/クラウド 冗長性 性能

2000年後半に始まった商用クラウドサービスは爆発的に成長し今でもその発展は続いている。この商用クラウドサービスは、その需要拡大に応えるために、サービス提供プラットフォームの大規模化を進めていった。今では一つのデータセンターに数万台のサーバを設置するようになっている。

需要拡大に対応するためには物理的な規模の拡大が伴うが、膨大な量のサーバを扱うためにはそれに応じた個数のL2ネットワークが必要である。さらに加えて、VM(Virtual Machine)仮想化技術の発展と安定性の向上で、物理的なサーバ１台の上で VM という形で複数の「論理サーバ」を提供できるようにった。この論理サーバ間の通信を基本にアプリケーションサービスが提供されることになり、クラウドプラットフォーム内での水平トラフィックが爆発的に増加することになった。

上記課題への対応として、例えば L2 over L3 というネットワークオーバーレイ方式を用いてL2拡張をするVXLANという仮想化技術の利用がある。このVXLANでは、上限1670万個のL2が用意できるので、実質的にはL2の個数の制限がなくなったとみてよい。このように仮想化されたL2が利用者に提供されることになる。さらにL2がL3上で提供されることにより、サーバや VM の分離・追加というコンフィギュレーションをL3の配下で、提供する仮想L2とはある程度独立に行えるようになった。そしてL3レイヤーであるから、トラフィックについても、L3の経路制御技術を使える。代表的なものでは、インターネットで長年安定的に運用されている技術である BGP を使ってのL3経路技術の利用である。この方式はIP Fabric 方式と呼ばれることが多い。その結果プラットフォームのスケールアウトも容易になり、さらに加えて、経路制御の効果から無駄な水平トラフィックの削減が実行できるようになった。L2を直接制御することに比べて、クラウドの運用が格段に安定するものになったのである。

本項目は、上記のクラウドの発展とともに利用されるようになった技術のうち、特にネットワーク技術に着目して、IP Fabric 方式によるプラットフォーム構築を実践する。堅牢な物理ネットワークを構築し、提供可能な論理的なL2ネットワークの拡張が目指すところであり、その技術を理解し利用できるようになることを目的とする。

DC/クラウド 冗長性 トラブルシューティング

データセンターなどの遠隔地にネットワーク機器、サーバ等を設置する場合、設定を変更するあるいは障害発生時に対応を行う時にいちいち現地に駆けつけるわけにはいかないし、対応可能なエンジニアを各データセンターそれぞれに常駐させるのは現実的ではないので、設置された機器をタイムリーにメンテナンスするためには、リモートからのメンテナンス環境があることが望まれる。そしてそのリモートメンテナンス環境は、一般的にはインターネット接続とは別の独立した個別ネットワーク経由で用意されることが多い。

ここでは、なぜそのような構成を選ぶのか、また、そのメリットはなにかを理解し、実際の操作に慣れることを目標とする。

さらにネットワーク機器やサーバの管理を行う以上、故障対応なども考慮しなければならない。このためネットワーク機器においてはシリアルコンソールを用いたシリアル接続が、サーバ機器では IPMI インターフェースを用いたメンテナンスが可能な環境を用意する。この課題では、ネットワーク経由での遠隔操作の感覚を掴むと共に操作に習熟する。

サーバ 仕組み・原理

ファイアウォール機器は、その配下のネットワーク全体に対してパケットフィルタリングの機能を提供するものであるが、Linuxサーバの各ネットワークインタフェースにも、外から受信するパケットや外へ出ていくパケットのフィルタリングルールを設定することで、（ファイアウォール機器が提供しない）独自のファイアウォール機能を持たせることが可能である。また、小規模ネットワークにおいては、サーバ自身にファイアウォール機能をもたせることで、管理する物理機器を少なくすることも可能となる。

本項目では、この Linux サーバに搭載されているファイアウォール機能の様々な設定を試すことを通じて、自分自身あてのパケットの受信可否の制御、自分自身から出ていくパケットの送信可否についての制御方法を習得する。あわせてファイアウォール・パケットフィルタリングというものの仕組みについて理解を深める。

OS トラブルシューティング

サーバ上には、CPU の数や搭載メモリの大きさ、ストレージの領域、ネットワークインタフェースの数やそれらネットワークインタフェースのスループット、また OS が用意している各種テーブルの大きさなど、さまざまなシステムリソースが存在する。そして、それらのうちどれかが枯渇していると、正常な動作とパフォーマンスを提供することが困難になる。

したがって、サーバの挙動が安定しなかったり、設計通りのパフォーマンスが提供されないなどの不具合が生じてしまった時には、システムリソースが枯渇していないかどうか調べることが重要になり、かつ、その原因を取り除くことが肝要となる。けれども、往々にして、再起動してその場を凌ぐというオペレーションになりがちなことも事実であるが、これでは根本原因をなくすことができず、常に運用の負荷がかかるという問題を生じさせてしまう。また闇雲なスケールアップやスケールアウトでの対応は、コスト的にも釣り合わないことが予想される。

本項目では、人為的に何らかのシステムリソースが枯渇している状態を発生させ、そのときに OS の挙動がどの様になるかを実体験するとともに、その枯渇理由とその原因となっているプロセスを調べ出す方法を習得する。その調査方法はいろいろあるだろうが、とにもかくにもシステムリソースの状況を把握することが肝心であるから、まずサーバ上のコマンドを駆使することによる状況の把握方法を身に付ける。その次に、枯渇状況を引き起こしているプロセスを特定し、そのプロセスを消去することによってシステムリソース枯渇状況が解消されることを体験する。そしてこの実践を通して、システムリソース枯渇という緊急時に速やかな対応ができるような技術を身に付ける。

仕組み・原理

インターネット上で広く使われているアプリケーションは、ネットワークの向こう側のサーバにデータが格納されている場合がほとんどである。そしてそのデータを利用するクライアントには、安全性を高めるために、サーバへのアクセスの際に何らかの認証が要求される。認証の方法は多種存在しており、サーバ上のアプリケーションはそのどれかを指定している。そのような関係性の上で、クライアント側はサーバの指定した認証方式に従って操作を行うのであるけれども、その方式に盲目的に従うのではなく、仕組みを理解した上で利用すれば、セキュリティの向上につながる。

認証機構の実装の一つとして、クライアントとサーバの協調の上で、「時間ベースの移動係数に対応したワンタイムパスワードアルゴリズムに基づいた手法」で作成されているものがある。本項目では、その認証機構を実際に開発実装し、サーバとクライアントで協調した認証機構の仕組みの一つを理解することを目的とする。そしてこの開発実装の経験を活かして、各種認証機構について評価する際の知見を増やす実力を養成することを目的とする。

具体的には、RFC 6238 を参考にして開発実装を行う。あわせて、セキュリティ分野の要素技術である秘密鍵、hash 関数というものの概念の理解を深め、利用の仕方を身に付ける。

サーバ 性能

サーバのパフォーマンス不足が露呈した時、それがシステムリソースの枯渇が原因であるならば、スケールアップやスケールアウトという方法で対処するというのが一般的である。しかしながら、それには相応の費用コストと時間的コストがかかる。一方で、システムリソースの枯渇内容によっては、サーバ自身の設定変更による能力増強で対応できることもある。その技術に馴染んでいれば、パフォーマンス不足の際の対応が柔軟になりコスト削減にも役に立つことになる。

本項目では、Linux OS が動作しているサーバの同時セッション数というシステムリソースが枯渇した場合を想定し、該当するカーネルパラメータを操作して、サーバの同時セッション数を拡大し能力をあげることを、カーネルパラメータの設定変更のみで行うという手法を実践する。そしてパラメータ変更後では枯渇していないということを確認する。

もちろんこの過程では、同時セッション数が確実に増えているのかどうかの確認をとる仕掛けも必要になるので、コマンドの利用またはツール開発などを通して同時セッション数を計測する方法を身に付ける実習も行う。

ネットワーク

通常、動的経路制御というものに触れる機会は多くない。企業ネットワークの場合には、ほとんどが静的経路制御でまかなっているか、動的経路制御を導入していても正しい使い方なのか不安に思う点も多々あると思われる。

ネットワークの規模が大きくなればなるほど、耐障害性や運用効率の観点から動的経路制御を用いたネットワーク構築は避けられないが、経路制御における基礎知識の理解が不十分な状態ではかえって不安定なネットワークにもなりかねず、また、大規模ネットワークを構築するために必要な高度な経路制御技術を身に付けることも困難である。

安定したネットワークを構築するためには

1. 複数の同一経路情報が存在する場合の経路選択
2. パケット高速転送の仕組み（RIB/FIB/Adjacencyテーブルの役割）
3. IGPとEGPの役割の違い
4. IGP（OSPF）とEGP（BGP4）でできること
5. ルータの防御及び経路制御におけるセキュリティ的な観点・ノウハウ 　　　　　etc

等の知識を正しく理解し使いこなすことが重要である。

本項目では、難易度の低い課題から高い課題へと実践を積み重ねながら、経路制御に必要な基礎知識の習得・再確認・補強を行いつつ、ISPクラスの経路制御技術を身に付けることを目的とする。

ネットワーク 仕組み・原理

しばしば「ネットワークがサチっている」という言い回しで、ネットワーク帯域が埋まっている状況を指すことがある。その際、ネットワーク帯域が埋まっているということはどの様にしてわかるのか？

一般的には、様々な計測ツール（古くは mrtg）のグラフをみて判断することが多いけれども、それらのツールはどの様にして計測データを取得してグラフを描いているのか。その仕掛けを理解すれば、システムの運用、特にネットワークの運用とモニタリング、さらにはネットワーク帯域量のプロビジョニングに役立てることができるようになる。

本項目では、ネットワーク上を流れているパケットの量というものはどのように計測されるものなのかを、SNMP というプロトコルを用いた測定ツールの実装を通して理解する。さらに加えて、ping コマンドでの計測データを利用して、転送速度の概算算出を行ってみる。また、サーバにはネットワーク利用の統計を取るコマンドが用意されているので、その出力の各項目の意味を理解できるようにする。これらを理解することにより、実際のネットワークの健康状態を把握することができるようになる。

ネットワーク 仕組み・原理

普段はほとんど意識せずに TCP/IP 通信を利用してネットワークを利用しているが、その TCP/IP プロトコルの理解を深めるためには、実際のパケットの挙動に精通することが必要である。そして精通するためには、リアルにパケットを眺めパケットの構造を理解することが有効である。

本項目では、まず既存のパケット解析ソフトウエアを利用して、自身がつながっているネットワーク上に流れているパケットの姿を確認する方法を学ぶ。次いで、自作実装の開発を行い、パケットの姿を確認する。この過程を通して、パケットの構造、プロトコルに関する理解を深め、将来求められるサービスに適合した新規プロトコル開発時に重要となるであろう知識を実践的に習得する。

ネットワーク 仕組み・原理

ルータ、特に外部との境界上に置かれるルータは、普段はあまり実際に触れることもなく、また、一度設定したらその設定の変更頻度は少ないものなので、ルータの設定をいろいろ試す機会はあまり多くない。けれども、設定によってパケットの流れを工夫することで、パケットの送信方向の振り分け・パケット受信の可否など L3 レベルでの制御が可能になるし、実際その制御を利用してネットワーク内でのパケットの流れが最適化されている。したがって、L3 ネットワークがあらたに追加されたり削除されたりした場合には、設定変更が必要になる。

加えて、ルータは、ネットワーク環境に対するルーティング以外の機能を提供することもできる（DHCP サーバ機能など）。

これらに習熟することによって、外部接続はもとより、大規模なLANを構築する上でも、必要に応じてセグメント化され、全体の統制がとれてパケットの流れが最適化されていて、かつ、必要な機能が提供されるネットワークを構築することができるようになるし、ネットワークの追加や削除の運用にもすばやく対処できるようになる。

本項目では、実際のルータ上での設定を通じて、ルータの仕組みについて理解を深めるながら、パケットの制御方法を実体験する。そして、ネットワークの設計構築の技量と運用技量を身につけることを目的とする。

OS 性能 仕組み・原理

クラウドを構成するサーバでは、Linux をはじめとした UNIX 系オペレーティングシステムを用いることがほとんどであり、そのサーバ上では、必要な機能を提供するために、複数のプロセスを同時実行している。

このサーバが実際に機能を提供する際に、レスポンスが悪くなることを、「動作が重い」「負荷が高い」と表現することがある。この負荷の高さを数値化したものがロードアベレージであるが、この数値の意味するところは意外と理解されていない。

また、ロードアベレージの数値が高くなる原因は、ただの計算処理によるものだけではなく、各プロセスのディスクアクセスやネットワーク通信などによるデータの読み込み書き込みなどの処理、プロセスどうしのシステムリソースの獲得競合、排他処理、そして OSによるスケジューリングなどによる複合的なものであるが、それがどのような場合に発生し、ロードアベレージの高騰にどのように関係しているのかも正確に把握されているとは言い難い。

したがって、システムの性能改善、安定運用、コスト最適化等が適切に判断できなくなるという問題が発生することになる。

本項目では、実際にロードアベレージを求めるプログラムを作成することで、ロードアベレージの数値の意味するところを理解する。さらにその実装の過程を通じて OS 上でのプロセスの状態というものを理解し、ロードアベレージとの関係を理解する。またプロセスの動作を制御する「カーネルのコンテキストスイッチ」の仕組みについても理解をすることで、プロセスの管理という視点からの OS の動き方を習得し、サーバの稼働状況の確認、安定運用、性能改善に必須の技術を習得することを目指す。

ネットワーク 仕組み・原理

IP 通信を行うためには、相手先の IP アドレスを知らなければならない。そしてその通信をイーサネット上で行うためには、相手先の MAC アドレスも必要になる。通常は相手先の IP アドレスが先に与えられ、その IP アドレスから MAC アドレス求めるという手順でことが進められていく。それを定義したものが ARP とよばれるプロトコルである。この ARP という仕組みが LAN 内の通信を支えている。したがって、その理解が曖昧であると、通信できないという不具合への対処や、ネットワーク規模に応じた適切な LAN の設計ができなくなる。

例えば、ARP はブロードキャストパケットを利用するものであるけれど、通信相手がルータをまたぐような場合、つまり異なる L3 セグメントにある場合には通常はブロードキャストは届かない。そのような場合でも通信できるのは、どのような仕組みからなのであろうか（そこにはデフォルトゲートウェイたるルータの存在が大きく寄与する）。また、ここで用いられるブロードキャストパケットは、L3（IP）でのブロードキャストなのか、それとも L2 (通常はイーサネット）でのブロードキャストなのか。はたまたその両方なのか。

また、相手先を探し出すたびに発行されるブロードキャストパケットがネットワーク全体に与える影響、負荷などを適切に評価して考慮しないと、無駄なパケットが飛び交いすぎるネットワークになってしまう。それらを総合的に判断してはじめて適切にセグメント化されたネットワークが構築できるようになるのである。

以上を背景として、本項目では、ARP の仕組みと振る舞い方を、パケットダンプを通して覗き見ることによって習得する。とりわけ、相手先が同一 L2 内であるときと、ルータをまたぐ異なる L3 セグメントにある場合の振る舞いの違いについて理解し、かつ、実際に発行されるブロードキャストパケットの構成についても理解する。あわせてスループット向上のための ARP キャッシュテーブルというものを保持する意義についても学ぶ。

冗長性 トラブルシューティング 仕組み・原理

LAN 上に L2 ループが発生すると通信が不可能になることはよく知られている事実である。しかしながら、ネットワーク機器の拡充や、冗長性の確保のためにいろいろと接続形態を変えたり追加したりする作業において、往々にしてついつい L2 ループが発生してしまうこともまた事実である。したがって、L2 ループがないことを要所要所で確認できると、作業がスムースに進み、手戻りも発生しなくなる。

本項目では、まず L2 ループの実態とそれが発生した時の挙動と問題点について理解を深める。そののち、L2 ループが発生していないことの検証方法を考案し、そのためのツール実装する。この過程を通じて、L2 ループ発生というトラブル時に対応できる技術を習得し、さらには、安定したネットワーク設計や構築を遂行できる技術的素養を身に付ける。

ネットワーク OS 性能 仕組み・原理

TCP の実装においては、Window と Window Scale というパラメータがフロー制御に用いられ、ack 応答の効率化に寄与している。一方通信時のネットワーク容量超えを減らし、輻輳発生を避けるために、スロースタートメカニズムが用意されている。これらは、安定的な通信を保証する TCP においては、なくてはならないものである。しかしながら、通常の利用ではこの両者をほとんど意識することがない。したがって、この2つの機能が実際の通信においてどのように働いているのかが、正確に理解されることは少ない。

上記の機能を司るパラメータのいくつかは、カーネルパラメータとして用意されているため、今あるネットワーク環境に適切な値を設定すれば、TCP通信のパフォーマンスが高まることになる。その技術を習得すれば、むやみにスケールアップやスケールアウトをせずとも、パラメータ設定のみでTCP通信のパフォーマンスを向上させ、コスト削減につなげることが可能になる。

本項目では、上記TCPの2つのアルゴリズム（フロー制御と輻輳制御）の振る舞いを、実際にカーネルパラメータの値を変化させながら実験を繰り返すことで理論と実践の両サイドから理解し、TCP通信のパフォーマンス向上にどのように寄与するか（しないか）を検証する。