備忘録 〜インフラ〜

こんにちは、うさです。 今回は「インフラ」について、 こちらの参考書をまとめていきます。

第1章 インフラエンジニアの仕事

インフラエンジニアの仕事は「インフラ設計」、「インフラ構築」、「インフラ運用」の3つのフェーズに分けられる 「インフラ設計」
  1. インフラを作る目的を理解する
  2. 目的を達成する為に必要な機能・性能などを要件としてまとめる
  3. 要件に合う企画書や設計書を作成する →どのくらいの費用で、どのくらいの期間で作れるかを算定
「インフラ構築」 インフラ構築作業は、機器の運搬・機器の組み立て・機器の取り付け・機器のインストールや設定・動作テスト・負荷テストに分けられる 「インフラ運用」 インフラ運用は下記のように区分できる
  • 障害対応:ハードウェアの故障の対応や急激なアクセス増への対策、不適切な権限設定によるアクセス出来ない状況の解消などがある
  • キャパシティ管理:構築したインフラの規模をアクセス数やデータ量に応じて適正化する
  • インフラ起因でない原因の切り分け:システムに障害が発生した場合、インフラ起因であるかプログラムおける問題かを切り分けて対応する

第2章 サーバ

サーバの選定

サーバスペックの決め方は3つの考え方がある
  • 実際の環境を試験的に構築し、測定結果から判断 →基幹系システムの中核の担うシステムや重要なシステムの場合
  • 仮決めしたサーバスペック機器を本番投入し、実際のハードウェアリソース利用状況を測定した上でサーバやサーバのパーツを増減していく →実際にリリースしてみないとアクセス量が判断できない場合
  • 消去法でスペックを絞り込んでいく →ある程度サービスの性質が特定されている場合
サーバスペックを決めた後は、ベンダーを選ぶ。 価格やサービスを総合的に判断する。 サーバのキャパシティを向上させるアプローチとして
  • スケールアウト:性能が足りなくなったらサーバの台数を増やす
  • スケールアップ:性能が足りなくなったらメモリの増設などでサーバの性能を増やす
の2つの方法がある。

CPU

CPU選定のポイント
  • パフォーマンス:求める演算能力を満たすか
  • 価格対比:求める処理能力、将来の拡張性から価格的に妥当か
  • 使うソフトウェアのライセンス体系:CPUのコア数やソケット数によって価格が変わるソフトウェアがある為、総コストを減らす為にCPUの種類や個数を調整
  • 消費電力:省電力CPUは動作周波数を落とすことで省電力を実現したCPU。単価は普通のCPUより上がるが、運用年数で計算する

メモリ

メモリの選定のポイント
  • 搭載容量
  • パフォーマンス:メモリコントローラが扱えるランク数制限ぎりぎりまで使い切り、マルチプロセッサ環境下でマルチチャンネルを実現するとパフォーマンスが向上
  • 拡張性:メモリスロットの数が限られるので、拡張が発生する場合は高価でも大容量メモリを選ぶ

RAID

RAIDのレベルは「0」〜「6」までの7種類が存在し、 RAID0と他のRAIDレベルを組み合わせたものも存在する。 よく使われるRAIDレベルと用途を見ていく
  • 「0」:耐故障性のないディスクアレイ(ストライピング) →ディスクI/O性能を上げたい場合に使う。耐障害性が弱い。ログ集計などの一時記憶領域などで使われる。
  • 「1」:二重化(ミラーリング) →耐障害性が強い。OSが入っているパーティションなどで使われる。
  • 「5」:ブロック単位でパリティ情報記録 →保存容量を多めに確保したい場合に使われる。ファイルサーバやログ保存等で使われる。
  • 「6」:ブロック単位で2種類のパリティ情報記録 →RAID5と用途は同じだが、耐障害性が強い。
  • 「10」:RAID1をストライピングしたもの →耐障害性とディスクI/O性能を満たす。データベースなどで使われる。
  • 「50」:RAID5をストライピングしたもの →保存容量確保とディスクI/O性能を満たす。ファイルサーバやログ保存などで使われる。
  • 「60」:RAID6をストライピングしたもの →RAID50と同様

仮想化

仮想サーバ・・・1台の物理サーバ上に複数のゲストOSを稼働させること 物理サーバと仮想サーバの特性
  • 物理サーバ:CPU使用率、ディスクI/O負荷・ディスク使用容量が大きい用途に向く。 →用途:データベースサーバ、アプリケーションサーバ
  • 仮想サーバ:CPU使用率、ディスクI/O負荷・ディスク使用容量が小さい用途に向く。 →用途:Webサーバ、開発サーバ、メモリDB
仮想化のメリット
  • コストダウン
  • ゲストOSのハードウェアリソース増減を容易に行える
  • 物理サーバが老朽化した際、ハードウェア交換が必要なのに対し、 ゲストOSは新しい物理サーバに仮想化環境を用意し、簡単に移行が出来る
仮想化のデメリット
  • 他のゲストOSが大量のハードウェアリソースを使うと、他のゲストOSの動作が不安定になる
  • 一度作られたゲストOSがその後使われなくなっても撤去されずに残りがちとなる

クラウド(IaaS)

クラウドは以下の3種類に分類される
  • SaaS:アプリケーションをサービスとして提供
  • PaaS:アプリケーション実行環境をサービスとして提供
  • IaaS:システムインフラをサービスとして提供
IaaSの特徴
  • 自社で物理サーバを持たずに使えるため、物理サーバを管理するエンジニアが不要
  • 利用申請後、短期間でOSがインストールされた状態ですぐ使える
  • 自社で物理サーバを持たないため、物理的成約を意識せず利用したい分だけサーバの増強が可能
  • 使った分だけ費用が発生する従量課金制
  • 自社で資産を持たずにすむので、サーバを買う発生する減価償処理が不要で、クラウド利用費は費用処理が行える
クラウドに向かない用途
  • 秘密情報を置く:自社で管理できないところで機密情報流出が発生するリスクがある。
  • 大容量ファイルの転送:ファイル転送が遅くなる
  • 大規模システム:自社で機器を持った方が安くなる

第3章 OS

Linux、Windows Server、UNIXについて代表的OSの記述

第4章 ネットワーク

ルータ ルータを選ぶポイント
  1. ISPやデータセンターなど、ルータを接続する先から提供される上位回線のインタフェースと一致したWAN側インタフェースを持つこと
  2. WAN側での通信帯域
  3. スループット:単位時間当たりのデータ転送量
  4. セキュリティ機能をルータにも求めるか:フィルタリング機能などを持たせるか
  5. 導入コスト
スイッチ L2/L3スイッチの役割
  • L2スイッチ:スイッチングハブ。 フレーム(L2スイッチではパケットではなくフレームと呼ぶ)が入ってくると、 宛先のMACアドレスを見て適切なポート番号にフレームを転送。 該当するMACアドレスが存在しない場合はLAN全体にブロードキャストを飛ばし、応答があったポートに転送。
  • L3スイッチ:ルータ機能付きのL2スイッチ。 パケットがが入ってくると、宛先のIPアドレスを見て適切なポートにパケットを転送。 該当するIPアドレスもしくはネットワークアドレスが存在しない場合は、デフォルトゲートに繋がるポートに転送。
L2/L3スイッチを選ぶポイント
  • インターフェースの速度とポート数
  • インテリジェントorノンインテリジェント
    • インテリジェント:スイッチにWeb接続もしくはtelnet接続することで各ポートの設定を変更することや、各ポートのステータスや通信量を確認することが出来る
    • ノンインテリジェント:サーバがネットワークに繋げるようにするだけであれがノンインテリジェントで十分である
  • スイッチング能力とスイッチング容量
    • スイッチング能力:一秒間のうちにどの程度のパケットを処理できるか
    • スイッチング容量:一秒間のうちにどの程度のバイト数を処理できるか
  • ハードウェア処理vsソフトウェア処理 通信量が大規模の場合ソフトウェア処理によってCPU使用率が上がってスイッチング能力に影響を与える場合がある

ネットワークケーブル

LANケーブル:LANケーブルは多くの種類が出ているが、通信品質に大きな差はない。 光ファイバーケーブル:
  • マルチモードファイバ:伝送距離が短いが安価
  • シングルモードファイバ:伝送距離が長いが高価

第5章 ストレージ

データを記憶する装置のことをストレージ
  • ローカルストレージ:サーバ内にディスクを搭載して用いる記憶領域 設置場所はコンパクトですが、搭載できるディスクの本数や拡張性は少ない
  • 外部ストレージ:サーバ外に用意するストレージ機器もじくはストレージ領域
    1. DAS:サーバに直結するストレージ機器。 DASを選ぶ際は、必要な実容量、パフォーマンス、耐障害性、拡張性を考える。
    2. NAS:ネットワーク経由で複数のサーバからアクセス可能なストレージ。 複数のサーバ間でデータ共有や複数のサーバでバックアップやログファイルを一カ所にまとめる用途で使われる。
    3. SAN:ブロックレベルのデータストレージ専用のネットワーク。 高速・高品質な環境を求める時に用いる。
外部ストレージを導入する動機としては、以下の4つが挙げられる
  • 記憶領域を大きく取りたい
  • ディスクI/O性能の向上
  • ストレージの統合・集中管理
  • 複数サーバ間でのデータ共有

第6章 購買と商談

インフラ構築の為の機器等の購入は、ベストは信頼のおける知り合いから良いベンダーを紹介してもらうこと。 ベンダーに来訪してもらう際、以下のことを把握しておくべき
  • 何を購買しなければならないのか
  • 購買しようとしているものの価値の相場の把握
  • 購買しようとしているもののトップシェアベンダー
  • 発注から納品までどれくらいの期間がかかるのか
初めて機器を導入する場合、導入テストを行う場合がある。 設置場所に収まるかといった物理的な確認、 必要な性能は出るかといったパフォーマンス測定、 サーバ等の接続確認。

第7章 データセンター

データセンターの選定 アプローチ方法としては、
  • 知り合いからの紹介
  • サーバベンダー等、付き合いのあるベンダーからの紹介
  • ホームページなどでモボ私意データセンターを探す
データセンターを選ぶポイント
  1. データセンターの立地
  2. サーバ設置台数:サーバ設置空間は後で増やすことが困難なため拡張性も考慮に入れる
  3. ラックは持ち込みか、貸し出しか:ラックとラックマウントには相性があり、取り付けられない場合がある
  4. 利用可能ボルト数:大型機器は200V電源が必須な場合がある
  5. 重荷重機器への対応:サーバルームの耐荷重の確認
  6. 防災レベル:災害に対しての備えがあるか
  7. UPS(無停電装置)や発電機の性能
  8. 廃棄処理:データセンターでやってくれるかどうか
  9. 搬入スペースや駐車場の有無
  10. リモートハンドサービスの有無:トラブル発生時、電話をかければ電源をオン/オフにしてくれるサービスがあるかどうか
  11. ユーザルームの有無:オペレータがデータセンターに常駐する為のユーザルームが借りれるかどうか
  12. ケージ(金網)の有無
  13. ネットワーク回線のコネクティビティー:自前でISPと専用回線契約できるかどうか
  14. イレギュラーな要望に強い
  15. 備品貸し出しの柔軟性
  16. 売店や宿泊施設の有無
  17. 費用:最終的には費用で決めることとなる

第8章 ソリューションとセキュリティ

ソリューション

監視ソリューション:機器の稼働状況を一括監視する為に監視ソリューションを利用する。 区分すると、SNMPを利用するものと各サーバにエージェントプログラムをインストールしてそのデータを収集するものがある。

セキュリティ

インフラにおいての守るべきものとは、
  • 顧客データ全般
  • 売上情報
  • メールデータ
  • 各種ドキュメント類
  • 各種ソースコード
  • 従業員名簿

第9章 インフラ運用

ボトルネックを解消する ITシステムでは一般的にボトルネックが一カ所あるだけでスステム全体のレスポンスに悪影響を与える。 ボトルネックのおこりやすい場所は
  • コアスイッチのキャパシティ
  • L2スイッチのキャパシティ
  • Webサーバのメモリ不足
  • データベースサーバのCPUやメモリ不足
  • データベースサーバのディスクI/O
MSP MSPとはITインフラの運用管理を代行してくれる業者 MSP業者を選ぶポイントは
  • 企業としての信頼性:コンプライアンス面、財務状況等も確認すべき
  • コミュニケーション力
  • 柔軟性
  • 技術力
  • 費用対効果

第10章 大規模インフラ

システム構成を決めるポイント
  • ベンダーサポートの必要性
  • 使用言語
  • アクセス量
  • 可用性
外部業者の利用が必要になってくる
  • 納品機器の開梱とラックへのマウント
  • 機器のセットアップ
  • 障害対策サポート
  • サーバルームの清掃
  • インフラ運営システムの開発
  • ハードウェア故障時の自動対応
CDN 画像や実行ファイルなどの静的コンテンツの配信にCDNを使う CDNは、サービス提供会社のサーバに変わってCDNベンダーが提供したキャッシュサーバにアクセスしてユーザが静的コンテンツを取得する CDN業者ぼ選び方
  • 品質:サービスダウンがないか、応答速度が十分であるか
  • サービスは国内限定か、それとも世界対象か
  • コスト:CDNを使う場合に想定される通信量とCDNを使わない場合のインフラ投資・運用費用の比較
リソース不足対策
  • 人的リソース不足
    • コアメンバー:インフラ全体を管理する
    • オペレーター:実作業を遂行する
    コアメンバーは大規模インフラの経験者が少ない上、転職市場に出回らない。 →新卒を数年かけて育成する方が早いかもしれない オペレーターは転職市場に多く存在する。 実務経験がなくても比較的短期間で育成が可能。
  • データセンタースペース不足 成長著しいWebサイトの場合ものすごい勢いでラックスペースを使っていく。 また複数のデータセンターにサーバを分離出来ない場合もあるため、全部のサーバを別のデータセンターに移転させなければならないこともある。
  • 機器不足 大規模サイトの場合、大量発注となる場合が多いため、ベンダー側との生産調整が必要になる
  • ネットワーク帯域不足 アップリンクが1Gbpsを超えるとコアルータのアップリンクも1Gbps増やさなければならない。 ルータがキャパシティの限界となった場合はデータセンターの移転も必要
  • 資金不足 成長基調にあるITベンチャー企業は成長期において資金不足に陥り、思うように必要インフラ投資をおこないことがある。 その場合には →中古品を活用する チューニングを行う →日頃付き合いのある企業に助けを求める →増資を求める

第11章 インフラエンジニアの成長

  • ドキュメントを読み込む力を付ける
  • カタログを読み込む力を付ける
小規模インフラと大規模インフラ 経験や身につけられることが違う
  • 小規模インフラ ITインフラ全般を少人数で扱う。 企画、設計、商談、構築、運用の経験ができることが最大のメリット。 予算が限られた中での最大の費用対効果を実現する為にチューニング等を行っていく。
  • 大規模インフラ ITインフラを大人数で分担して構築、管理していく。 特定の分野に対して、高度なスキルが必要となる。 予算は多くかけられる分、可用性が求められる。
まとめ インフラ構築において、こういった場合にはこれを選ぶといいといった具合に、 一つ一つのケース毎にわかりやすく解説がなされており、 自分がインフラ構築する際にはしっかりとデータを収集した上で、行く通りの選択肢から最適なものを選ぶようにしていきたい。 以上、インフラについての備忘録を終了する。

Usami Go

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です