インフラエンジニアは何をやっているのか
「インフラエンジニア 」の業務範囲が広すぎる！
ということで、「そもそもインフラとはなんぞや」というところから掘り下げて行こうと思います。
コンピュータシステムにとってインフラとは
そもそもコンピュータシステムにとってインフラとは何だろう？
インフラというのもともと、サービスや機能を提供するための土台を指す。
ことにコンピューターシステムにおいては以下のような要素が「システムインフラ」と呼ばれる。
- ハードウェア
- ネットワーク
- オペレーションシステム
- ミドルウェア
システムインフラでは利用者が不都合なくサービスを利用するために、安定したサービスを提供すること、また障害に備えた仕組みづくり、将来の拡張性などが求められる。
実際に参加するプロジェクトは保守や運用から入り、手順書作成したりレビューをしたりというところから始まる。そして、ある程度仕事内容を理解してから設計を任せてもらうことが多いと思う。（設計できるまでにだいたい2、3年かかる？）
インフラエンジニアが担う設計範囲
そしてインフラエンジニアが担う設計範囲は以下の3点。
これらの設計に基づき、以下のような製造、テスト、運用保守、監査といった業務が発生する。
製造工程
前工程での設計に従って、システム環境を構築するのがインフラでの製造工程に該当する。具体手にはOSのインストールやミドルウェアの設定など。
システム設計の内容通りに環境構築を行うため、まずは構築手順書や構築後の検証手順書を作成する。
テスト工程
テスト工程では、構築したシステム上で開発したOS、ミドルウェア、アプリケーションなどが要件定義、設計通りに正しく動作することを確認する。
テスト工程には、以下のようなテストがある。
単体テスト
プログラムを構成する部品ごとに、動作確認をするテストのこと。インフラエンジニアによる単体テストでは、サーバ単体でのOS、ミドルウェアによる機能確認を行う。
結合テスト
部品間の接続（インターフェース）の動作確認をするテスト。インフラエンジニアによる結合テストでは、サーバ間のOS、ミドルウェアの機能間連動確認を行う。例えばWebサーバとDBサーバを連携させるようなテスト。
システムテスト
本番運用を想定したシステム全般に関するテスト。本番運用を想定するため、日次、週次、月次、年次に発生するシステムの運用を実際に稼働させて動作確認や検証などを行い、システム要件が満たされているかを確認する。
例えば、以下のようなことを検証する。
・ピーク時のレスポンスおよびスループットが要件を満たしていることを検証
→高負荷状態でもシステムリリースに問題ないか
・障害発生時や災害発生時のシステム切替・回復・業務復旧の一連のプロセスを検証
→機能および手順の妥当性・通常日、特定日などイベントを狙った実際の稼働シナリオテストを検証
→実際の稼働時と同じ状況下で業務設計を行い、機能面や性能面での問題がないか
運用テスト
システム運用部が実際のオペレーションマニュアルに基づき、本番同様の動作環境と運用体制でシステム全体の機能や運用についてテストを実施する。
ユーザ受け入れテスト
導入後のユーザ業務利用を想定したテスト。
業務利用ユーザが業務要件を充足しているかを確認して行う。また業務フロー、事務手続きと整合性が取れているかの最終確認も打鍵して行う。
運用保守工程
システム稼動の開始後、システムの安定稼動を目的にシステムの運用保守を行う。
運用保守業務の代表例は以下の通り。
監視運用
障害や不具合の早期発見を目的に行う運用。
以下の5点を行う。
プロセス監査
サービス継続のためにサーバ上で稼動し続ける必要のある特定のプロセスが支障なく稼動しているかを確認する。例えばWebサーバであればhttpプロセス、APサーバであればWebアプリケーション・サーバのプロセス（Javaプロセス）が監査対象のプロセスとなる。
メッセージ監査
エラーログ監査のこと。システムに異常が発生した時、OSや製品にエラーメッセージが出力されるので、これを定期的に監視する。
リソース監査
システムを構成するサーバのCPU、メモリ、ディスクなどの各種リソースが適切に使用されているかどうかを監視する。監視基準として、一般的には各リソースの使用率が使われる。例えばCPUであれば、要件定義の段階で「CPU使用率が＠%以下となるシステム構成を採用する」といった形で定義されるので、この値を越えることがないように監視を行う。
そして監視結果として、ある通知が行われた場合、この通知が一時的なものだったのか、継続的に発生する可能性があるものなのかを見極める。
ハードウェア監査
通常、ハードウェアになんらかの障害が発生した場合、その障害発生を示すログファイルが出力される。ハードウェア監査では、これらログファイルにエラーが出ていないことを継続的に確認する。
ジョブ監査
バッチ処理が予定した時間に終わっている、あるいは予定された時刻までに完了している、といった定期的な実施処理が想定の範囲内に開始、完了しているかを監視する。
実行すべきジョブが全て正常に実行され、正常に終了されているかの監視を行うと共に、遅延が生じていないかを確認する。
バックアップ運用
バックアップにはシステムバックアップとデータバックアップの2種類ある。
システムバックアップはOSを含むイメージバックアップ。システム障害からの復旧を目的としている。
データバックアップはデータ破損や紛失に備えて復旧するためのバックアップ運用。
なぜバックアップが必要なのか？
業務で使用するデータは、業務サーバが使用している「物理的なディスク上」に書き込まれています。しかしながら、残念なことにディスク装置は10年利用出来るものではありません。
ディスクは磁性体がついた円盤をモーターで回転させながら利用するストレージ媒体であるため、必ずいつかは壊れてしまいます。
さらに、予測できない不慮の事故のためにディスク装置が壊れてしまう可能性もあります。ディスク装置が壊れていなくてもOSが起動しなくなる可能性もあるのです。
HDDはディスクを物理的に円盤を回すので衝撃で傷ついていつか壊れてしまうし、SSDのフラッシュメモリも年々劣化するらしい。
こうしたディスク装置はバックアップが必要。
ウイルス対策運用
アンチウイルスソフトの導入やパターンファイルと呼ばれるワクチンソフトを定期的に更新するなど。
バッチ、ファームウェア運用
ウイルス対策同様、システムに悪影響を及ぼす可能性を排除するためにセキュリティパッチやファームウェアの適用を定期的に行う。
自動化運用
定期的なサーバの再起動やログ転送などを自動で運用する仕組みのこと。
シェルスクリプトでの自動化処理開発など。
ITサービスマネジメント
ITサービスを運用する上で、問い合わせ対応などの業務も欠かせない。
ITサービスマネジメントのベストプラクティス集であるITILには以下のような業務が載っている。
サービスサポート：日常的なサービス運用
・サービスデスク：利用者からの問い合わせを受け付ける
・インシデント管理：障害などのサービスを阻害する事象（インシデント）に対応し、サービス状況を回復する
・問題管理：インシデントが発生した根本的な原因を解決し、未然に防ぐ
・サービス資産管理および構成権利：所有するIT資産を正確に把握し、管理する
・リリース管理および展開管理：実際に変更を実施し、ユーザー教育などを行う
障害対応の一般的な手順は以下の通り。
受け付けと記録→分類・判別→（可能なら）応急処置→優先度決定→原因究明・解決
障害対応の流れを書くとこんな感じなのだけど、これに必要なスキルは地味だが重要。
・事象を正確に記録すること
・ステークホルダーに事象を共有すること
・事象の優先度を決定すること
・原因を究明すること
・対策（するかどうかを含めて検討し）をすること
サービスデリバリ：中・長期的なサービス業務
・サービスレベル管理：サービス品質（水準）について合意・管理する
→利用者と提供者がサービス水準について交わす合意のことをSLAと呼ぶ
・ITサービス財務管理：会計処理や課金処理などを実施する
・キャパシティ管理：負荷に適切に対応できるか監視し、必要ならば修正する
・ITサービス継続性管理：緊急事態における復旧処置などを検討・実施する
・可用性管理：信頼性や保守性を高める
この本で取り上げられていたのは要件定義〜基本設計のフェーズ。
障害復旧を目的としたAWS利用
障害復旧を目的としたAWS利用
信頼性
ディザスタリカバリ（システム障害が発生した際に、システムを迅速に復旧するための仕組み）を用意することも、信頼性向上のためには必要だ。構成パターンとしては、大きく4つの方法がある。
1つ目は、「バックアップ＆リストア」という方法だ。バックアップファイルのみを別のリージョンに退避しておく考え方である。2つ目は、「パイロットライト」という方法。これは、停止した状態のサーバーを別のリージョンに用意しておき、障害発生時に立ち上げるというものである。
非常時の際に、サービスを迅速に別のリージョンに展開したい場合には、「ウォームスタンバイ」という方法が効果的だ。これは、平常時は最小限のリソースでサーバーを起動しておき、非常時にサーバーをスケールさせるというものである。また、より信頼性を高めるには、常時複数のリージョンを用いてサービスを提供する「マルチサイト」という方法が用いられる。
優れたアーキテクチャを生むAWSベストプラクティス。運用者が守るべき5つの柱 (1/2)：CodeZine（コードジン）
パイロットライトを実装するのは以下の通り。
(1)アドレスをインスタンスに紐づけるまたはElastic Load Balancingを利用してトラフィックを複数のインスタンスに分散させる。
(2)CNAMEでEC2インスタンスやElastic Load Balancingを指定するようにDNSレコードを更新する。
※CNAMEレコードは正規ホスト名に対する別名を定義するレコード。
特定のホスト名を別のドメイン名に転送する時などに利用します。
※正規ホスト名はAレコードが登録されている必要があります。
※特定のファイルやサブディレクトリを指定する事はできません。
※ホスト名なしのCNAMEレコードは登録することができません。
※パイロットライト環境では定期的に変更されるデータベースをレプリケートする必要がある。このため本番データベースをRDSに継続的に複製する。
https://aws.koiwaclub.com/wp-content/uploads/2018/09/AWS_Disaster_Recovery_01242012.pdf#page=11
※Lambda関数はデータベースの変更をレプリケートするのに信頼性が低い。
NoSQL vs SQL
NoSQL と SQLの違い
SQL and NoSQL represent two of the most common types of databases. SQL stands for Structured Query Language and is used in most modern relational database management systems (RDBMS). NoSQL means either “no SQL” (it does not use any SQL for querying) or “not only SQL” (it uses both SQL and non-SQL querying methods). NoSQL is generally used in a non-relational database (in that it doesn’t support foreign keys and joins across tables). The differences between SQL vs NoSQL databases include how they are built, the structure and types of data they hold, and how the data is stored and queried.
Relational (SQL) databases use a rigid structure of tables with columns and rows. There is one entry per row and each column contains a specific piece of information. The highly organized data requires normalization, which reduces data redundancy and improves reliability. SQL is a highly-controlled standard, supported by the American National Standards Institute (ANSI) and the International Standards Organization (ISO).
Non-relational databases are often implemented as NoSQL systems. There is not one type of NoSQL database. There are many different schemas, from key-value stores, to document stores, graph databases, time series databases and wide-column stores. Some NoSQL systems also support “multi-model” schemas, meaning they can support more than one data schema internally.
Unlike the ANSI/ISO processes for the SQL standard, there is no industry standard around implementing NoSQL systems. The exact manner of supporting various NoSQL schemas is up to the various individual software developers. Implementations of NoSQL databases can be widely divergent and incompatible. For instance, even if two systems are both key-value databases, their APIs, data models, and storage methods may be highly divergent and mutually incompatible.
NoSQL systems don’t rely on, nor can they support, joined tables.
AWS が提供する主な NoSQL サービス
- Amazon DynamoDB
- Amazon ElastiCache
Amazon DynamoDB
※DynamoDB は Key-Value 型データベース。
どのようなデータアクセスがされるかを設計段階で検討する必要があり、設計後の柔軟な検索要件変更には弱い。
DynamoDB は、パーティションキーによる完全一致、もしくはパーティションキー＆ソートキーの組み合わせから検索クエリーを発行し、Item（レコード）を取得します。
この点はRDBMSの複合プライマリーキーと似ていますが、DynamoDB は、パーティションキーによる完全一致と、パーティションキーとソートキーの組み合わせでしか効率良い絞り込みが行えません。（ 効率よくデータアクセス可能なキー設計を行えば、プロダクトがスケールしても低レイテンシーを維持可能 ）
RDB設計者のための DynamoDB の解説！開発経験者が語る DynamoDB 設計入門🤔 | Ragate ブログ
- DynamoDB では、特定のパーティションにデータアクセスが集中するような設計は好ましくありません。（ これをホットパーティションと呼びます ）
- パーティション内のデータは裏側で自動的に３つのアベイラビリティゾーンへ、レプリケーションされます。これによって高い可用性が実現されています。
- ElasticSearch は検索用途に主に使用されるサービス
S3についての覚書
データの整合性
- Amazon S3 では、すべてのリージョンで S3 バケットの新しいオブジェクトの PUTS およびDELETEの "書き込み後の読み込み" について整合性を提供している。
- オブジェクトが作成される前にキー名に対して HEAD または GET リクエストを行い、その直後にオブジェクトを作成した場合、結果整合性のために後続の GET がオブジェクトを返さない可能性がある。
- S3Glacierではアーカイブソリューションに用いられる。
暗号化
S3 オブジェクトには､S3 によって管理されるキーを使用する SSE-S3､AWS KMS によって管理されるキーを使用する SSE-KMS､ユーザーが管理するキーを使用する SSE-C の 3 つのサーバー側の暗号化オプションがあります｡
サーバー側の暗号化を使用すると、Amazon S3 はオブジェクトをディスクに保存する前に暗号化し、オブジェクトをダウンロードするときに復号します。新しい Amazon S3 暗号化 & セキュリティ機能 | Amazon Web Services ブログ
SSE-S3
暗号化や鍵管理について、自社のルールにあったオプションを選ぶ必要があります。特に制約がないのであれば、SSE-S3を利用することが一番簡単です。
CSE
一方で、セキュリティの要件が非常に厳しく、アプリケーション側でデータを暗号化する必要がある場合は、CSEを利用することになります。
KMS
Amazon S3 は AWS KMS カスタマーマスターキー (CMK) を使用して Amazon S3 オブジェクトを暗号化します。AWS KMS が暗号化するのはオブジェクトデータだけです。オブジェクトメタデータは暗号化されません
Key Management Service (SSE-KMS) に保存された CMK によるサーバー側の暗号化を使ったデータの保護 - Amazon Simple Storage Service
「いつ」「誰が」使用したか
データ保護には、転送時（Amazon S3 との間でデータを送受信するとき）のデータを保護するものと、保管時（Amazon S3 データセンター内のディスクに格納されているとき）のデータを保護するものがあります。Secure Socket Layer/Transport Layer Security (SSL/TLS) またはクライアント側の暗号化を使用して、転送中のデータを保護できます。Amazon S3 で保管時のデータを保護するには、次のようなオプションがあります。
可用性
高スループットのための水平スケーリングとリクエスト並列化
転送のスループットを高めるために、Amazon S3 では複数の接続によってデータの GET や PUT を並列で行うアプリケーションを使用することをお勧めします。このような並列化は、AWS Java SDK の Amazon S3 Transfer Manager でサポートされています。
アプリケーションで REST API を使用して Amazon S3 にリクエストを直接発行する場合
HTTP 接続のプールを使用して、一連のリクエストで各接続を再利用することをお勧めします。
リクエストごとの接続セットアップを回避すると、各リクエストで TCP スロースタートと Secure Sockets Layer (SSL) ハンドシェイクを実行する必要がなくなります。REST API の使用については、Amazon Simple Storage Service API Reference を参照してください。
Amazon S3 Transfer Acceleration
世界中のクライアントと Amazon S3 を使用する特定のリージョンのアプリケーションの距離によるレイテンシーを最小限に抑える、またはなくすために有効です。
次のような場合は、バケットに対して Transfer Acceleration を使用することが推奨されます。
Amazon S3 Transfer Acceleration - Amazon Simple Storage Service
監視
CloudTrail
CloudTrail は、AWSの各サービスに対するAPIコールを追跡するサービス。
オブジェクトの取得や削除といったS3のイベントをキャプチャすることができる。
キャプチャしたイベントログはS3バケットに保存できる。
CloudTrail の [Event history] 機能では、管理イベントのみサポートされています。すべての管理イベントがイベント履歴に表示されるわけではありません。
イベント履歴に表示されないのは、以下。
- データイベント（S3バケットへのオブジェクトのPut・Get等）
- 情報表示(Describe)系（管理イベントだが非表示）
イベント履歴だけでは不十分な場合、データイベント（証跡情報とも）を用いる。
管理イベントは90日間保存されるのに対し、データイベントではS3に保存されるため、保存期間はS3の設定に依存する。
CloudWatchLogs
AWSサービスに限らず、様々なサービスのログファイルを監視するサービスです。上記のCloudTrailと組合わせることで、S3に対するイベントログを監視できます。
また、このサービスには特定のログを検知できるフィルター機能が備わっています。フィルター機能を利用することで、S3オブジェクトの取得イベントのログを検知し、さらにその検知をトリガーとして別のサービスを起動する（メール通知する等）、のようなことができます。
※S3サーバーアクセスログにはバケットに対するリクエストの詳細が記録されますが、S3オブジェクトレベルのAPIオペレーションのログは記録されない。
※CloudTrailでも同様に、S3オブジェクトレベルのAPIオペレーションのログは記録されない。
■
High-Level Data Link Control (HDLC) is a bit-oriented code-transparent synchronous data link layer protocol developed by the International Organization for Standardization (ISO). The standard for HDLC is ISO/IEC 13239:2002.
HDLC provides both connection-oriented and connectionless service.
HDLC can be used for point-to-multipoint connections via the original master-slave modes Normal Response Mode (NRM) and Asynchronous Response Mode (ARM), but they are now rarely used; it is now used almost exclusively to connect one device to another, using Asynchronous Balanced Mode (ABM).
High-Level Data Link Control - Wikipedia
Integrated Services Digital Network (ISDN) is a set of communication standards for simultaneous digital transmission of voice, video, data, and other network services over the digitalised circuits of the public switched telephone network.
Since its introduction in 1881, the twisted pair copper line has been installed for telephone use worldwide, with well over a billion individual connections installed by the year 2000. Over the first half of the 20th century, the connection of these lines to form calls was increasingly automated, culminating in the crossbar switches that had largely replaced earlier concepts by the 1950s.
ADSL quickly replaced ISDN as the customer-facing solution for last-mile connectivity. ISDN has largely disappeared on the customer side, remaining in use only in niche roles like dedicated teleconferencing systems and similar legacy systems.
Integrated Services Digital Network - Wikipedia
