システム基盤エンジニアというと、「サーバーを作る人」というイメージを持つかもしれません。
実際のシステム開発では、サーバーを構築するだけでは仕事は終わりません。アプリケーションを動かすためのCPUやメモリ、ストレージを用意し、OSや共通設定を整え、ネットワークやデータベースと接続します。本番稼働後には監視、ログ、ジョブ、バックアップが必要になり、障害が起きれば原因を切り分け、必要に応じて切り替えや復旧を行います。
システム基盤エンジニアは、こうした仕組みを横断し、アプリケーションが動き、運用でき、障害が起きても復旧できる土台を成立させる仕事です。会社やプロジェクトによっては、基盤SEやインフラエンジニアなど、異なる呼び方をすることがあります。
私自身、これまでサーバー、ネットワーク、Oracle DBA、AWSへのクラウド移行、基盤統括など、立場を変えながらシステム基盤に関わってきました。その中で感じるのは、基盤の仕事は製品を設定すること以上に、どこまで作り、どう維持し、問題が起きたらどう戻すかを設計する仕事だということです。
この記事では、システム基盤・クラウドエンジニアの仕事を、
整える、保つ、戻す
という3つの視点から、実際に経験した大規模システムの事例も交えて説明します。SEの職種全体と、それぞれの役割の違いについては、次の記事で整理しています。
システム基盤エンジニアとインフラエンジニアの違い
インフラエンジニアは、サーバー、ネットワーク、ストレージ、クラウドなど、ITインフラを扱うエンジニアの総称としてよく使われる呼び方です。厚生労働省のjob tagでも、「システムエンジニア（基盤システム）」の別名としてインフラエンジニアが挙げられており、両者に業界共通の明確な境界があるわけではありません。
大規模なSIの現場では、サーバーやネットワークといった個別領域だけでなく、OS、ミドルウェア、監視、ジョブ、バックアップ、可用性、運用設計まで含めて、アプリケーションが動く共通基盤を横断して設計・構築する役割を「システム基盤」と呼ぶことがあります。
本記事のシステム基盤エンジニアは、この横断する役割を指します。個別のサーバーやAWSサービスを設定することではなく、システムを整え、保ち、戻すために基盤全体を成立させることが仕事の中心です。
システム基盤・クラウドエンジニアは何をするのか
システム基盤の担当範囲は広く、プロジェクトによって境界も変わります。大きく分けると、構築とサイジング、環境と標準化、監視と運用、可用性とデータ保護、クラウドとコストといった領域があり、それぞれを個別に見るのではなく、システム全体としてつながるように設計します。
図 規模によっては、業務アプリケーション以外のすべてを担当することもあります
大規模システムでは、アプリケーション、サーバー、ネットワーク、DB、運用などに担当を分けます。基盤側でも、サーバー、監視、バックアップなどを別チームが担当することがあります。
例えばWeb/APサーバーを一台追加する場合、必要なCPUやメモリだけを決めればよいわけではありません。既存サーバーとOS設定をそろえ、必要なネットワーク通信を許可し、DBへ接続できる状態にします。監視やログ収集にも組み込み、必要であればバックアップ対象に加え、障害時にどう扱うかまで決めます。
一つの変更が複数の担当領域へ影響するため、基盤では周辺チームとの接続まで考えて設計する必要があります。
図 アプリケーションを動かすために、複数の基盤領域が相互に関係するイメージ
このように、基盤エンジニアの仕事は個々の製品を構築することでは終わりません。まず必要なリソースを見積もり、実際の業務を動かせる構成を決めるところから始まります。では、その設計はどこから始まるのか。次章から順に見ていきます。
基盤設計は必要なリソースを決めるところから始まる
システムを作るには、CPU、メモリ、ストレージ容量、ディスクI/O、サーバー台数など、必要なリソースを決めます。この作業をサイジングと呼びます。
既存システムの更改であれば、現在のCPU使用率、処理件数、データ量、ピーク時の負荷などが判断材料になります。
新規システムでは、想定する業務量、同時実行数、バッチ件数、レスポンス要件などから必要性能を見積もり、机上計算だけでは判断できない部分を実機やPoCで確認します。
私が初めて本格的な実機サイジングを担当した2010年前後の案件では、大きな手戻りを経験しました。
約1万件のデータを処理するバッチに、5TPSの性能が求められていました。
ここでは、バッチで処理する1件を1トランザクションとして扱います。AP基盤チームと一緒にバッチ用フレームワークを検討し、Sun Fire T1000を検証用に借りて、プロトタイプアプリケーションによる性能試験を始めました。
最初の問題は、検証に使うサーバーの選び方でした。当時は、マルチコア化に加え、1コアで複数のスレッドを実行するCMT（Chip Multithreading）型のCPUが登場していた時期で、私自身も実機サイジングの経験がまだ十分ではありませんでした。
検証に使用したSun Fire T1000は、UltraSPARC T1を搭載し、最大8コア・32ハードウェアスレッドを同時に処理できる、並列処理によるスループット向上を重視したサーバーでした。
ところが、実際にバッチ実行中のCPU使用状況を確認すると、32スレッドのうち実質1スレッドしか使えていませんでした。
図 Sun Fire T1000でバッチ性能を見誤った理由
バッチ処理自体が並列化されていなければ、サーバー側に多数のハードウェアスレッドがあっても、一つの処理が自動的にそれらへ分散されるわけではありません。
つまり、32スレッドを持つことを「CPU性能が高い」と捉えていましたが、今回のバッチで必要だったのは、並列処理によってサーバー全体のスループットを稼ぐ特性ではなく、バッチ処理を所定時間内に終わらせるための1処理あたりの性能でした。
Web/AP用途を意識したサーバーを使ってバッチ性能を検証したものの、ワークロードとの相性を十分に考えられていなかったことが分かり、最終的にはバッチ処理に適したサーバー構成へ見直しました。
もう一つの問題は、アプリケーション側の処理方式でした。
バッチ用のフレームワークであるにもかかわらず、1件を処理するたびにDAOを介してDBアクセスを繰り返す構造にしていました。
図 1件ごとにDAO経由でDBアクセスしていたバッチ処理の構造
データを実際に流すとDBアクセスのオーバーヘッドが積み重なり、要求した5TPSを大きく下回りました。駆動データをあらかじめ読み込み、1件ごとのDBアクセスを減らす方式へ変更しました。
サーバー側についても、プロトタイプで確認した1処理系あたりの実測性能を基準に、検証機と購入予定機の性能差を当時利用していたSPECint系の指標などで比較しました。利用できるCPUリソースと実測値を踏まえて並列度も検討し、4並列程度で要求性能を満たせると見積もり、最終的には実機でも5TPSを達成しました。
容量については、過去のデータ増加量から年間約20GB増えると見積もり、5年間で約100GB増加しても問題がないように設計しました。
この経験で学んだのは、サイジングはCPUやメモリの数字だけでは決まらないということです。アプリケーションがどうDBへアクセスするのか、処理をどこまで並列化できるのか、実際のデータ量ではどうなるのかまで見なければ、性能を判断できません。
当時は、実機で実際の処理を流すことの重要性を痛感しました。十数年後、AWSへのクラウド移行でも、私は形を変えて同じ問題に直面することになります。
図 要求5TPS → プロトタイプ → 性能不足 → AP方式／サーバー構成見直し → 実測と性能指標で評価 → 並列化 → 5TPS達成
本番・開発・試験環境をどう分けるか
システム開発では、本番環境だけを作るわけではありません。開発、総合試験、性能試験、研修など、それぞれ目的の異なる環境が必要です。
すべてを本番と同じ構成にすれば検証できる範囲は広がりますが、費用も大きくなります。何を確認するための環境なのかを先に決め、その目的に必要な構成へ絞ることが重要です。
ある大規模システムでは、本番リリース前のアプリケーションを検証するため、本番に近い構成の試験環境を用意しました。一部の冗長化は省略しており、通常の総合試験には使えても、冗長構成そのものを確認する試験には使えません。
利用者研修用には、業務操作を再現できる最低限の小規模環境を別に用意しました。性能試験では、本番相当量のデータを搭載できる専用環境を使います。同じ「試験環境」でも、目的によって必要な構成は大きく異なります。
さらに、本番では数十の外部組織からデータを受け取るシステムだったため、外部連携試験では接続先を模擬する多数のDBインスタンスも必要になりました。接続先の規模を大・中・小などに分類し、すべてを最大構成にしないことでライセンス費用を抑えました。
AWSでは、こうした環境を常時稼働させるとコストが大きくなります。CloudFormationなどを利用し、必要なときに構築・利用できるようにすることで、リソースを効率よく使いました。
図 本番・総合試験・性能試験・研修環境の使い分けイメージ
環境設計は、本番環境を何個コピーするかを決める仕事ではありません。その環境で何を確認するのかを決め、必要な性能、データ量、外部接続、冗長性を選ぶ仕事です。
環境優先するもの省略できるものの例本番前検証本番との構成差を小さくする一部の冗長化研修業務操作の再現性能、冗長化性能試験本番相当データ、性能常時利用外部連携試験接続先の再現接続先ごとの最大スペック
OSや共通設定は「どこまでそろえるか」を設計する
サーバーが数台なら、一台ずつ設定しても管理できるかもしれません。数十台、数百台になると、個別設定では構築にも運用にも大きな負荷がかかります。
同じLinuxサーバーでも、ユーザー、ディレクトリ、ログ出力先、OSパラメータ、DNS、時刻同期、セキュリティ設定、監視設定などがサーバーごとに異なれば、変更や障害調査が難しくなります。「このサーバーだけ設定が違った」という差異が、障害時の切り分けを複雑にすることもあります。
別の共同利用型システムでは、Web/AP、DB、運用管理など、役割ごとにベースとなるAMIを用意しました。
AMIには用途に応じてApache／Tomcat、Oracle、Hinemos／Zabbixなどの監視製品、バックアップ製品、セキュリティ製品などをあらかじめ組み込み、内部では標準構成にパッケージ名を付けて提供しました。
Web/APサーバーも一種類ではなく、業務用途によって必要な設定が異なるため、複数の標準パターンを用意しました。セキュリティ製品やOSのセキュリティ設定についても、利用組織ごとに一から決めるのではなく、共通して守る設定は標準側へ組み込み、業務固有の例外だけを差分として管理しました。
標準化したからといって、すべての利用者へ完全に同じ設定を強制したわけではありません。「この項目も監視したい」「夜間のWeb/APへの外部アクセスは異常として扱いたい」といった固有要件には、個別設定で対応できるようにしました。
難しいのは、どこまで共通化し、どこから個別対応にするかです。何でも個別対応にすれば要望には合わせやすくなりますが、将来の変更や保守が複雑になります。すべてを共通化すれば、必要な個別要件を吸収できません。
追加設定の手間、変更時の影響、維持管理のしやすさを見ながら境界を決める必要があります。基盤の標準化とは、すべてを同じにすることではなく、共通部分を増やしながら、必要な差分だけを管理できるようにする設計です。
図 標準AMI／標準パッケージを作りA環境・B環境・C環境へ必要な個別差分だけ追加する
基盤の標準設定を具体的な設計値へ落とし込む工程については、基本設計・詳細設計の記事でも扱っています。
監視まで設計して初めて使える基盤になる
サーバーが起動し、アプリケーションが動けば構築作業としては一区切りに見えます。本番運用では、それだけでは足りません。
CPUやメモリ、ディスク使用率、プロセス、ログ、通信状態などを監視し、どの状態を異常とみなすかを決める必要があります。監視項目が多ければよいわけでもありません。
ジョブについても、起動時刻を決めるだけではありません。前の処理が終わらなかった場合、異常終了した場合の再実行、翌朝の業務開始までに完了しない場合の扱いまで決めます。こうしたジョブ、ログ、バックアップなど、本番運用全体をどう成立させるかは運用設計で扱う重要な論点です。
監視、ジョブ、ログ、バックアップなどを本番運用へ落とし込む考え方は、以下の運用設計の記事で詳しく整理しています。
私は、監視対象を増やしすぎて苦労した経験があります。
ある案件では、顧客要件としてSNMPによる監視も必要になり、標準MIBを広く登録しました。結果として、機器が正常に動いているにもかかわらず、運用上ほとんど意味のないものを含めて大量のアラームが発生しました。
大規模システムでは、システムテスト中に数か月間エージングし、その間に発生したエラーやアラームを専門チームで評価することがあります。この案件ではアラーム量が非常に多かったため、テスト工程を待たず、構築中から一つずつ内容を確認して不要な監視を減らしました。
SNMPですべてを拾うのではなく、JP1などの監視機能と役割を分け、本当に運用で対応が必要な異常を中心に監視する構成へ寄せました。
監視できる項目を全部登録することが、良い監視設計ではありません。アラームを受けた人が、何が起きていて、次に何を確認すればよいのか判断できる状態にすることが重要です。
監視項目や閾値、通知、一次対応については、以下の記事でさらに詳しく扱っています。
バックアップは「取れている」より「戻せる」が重要
バックアップについて「毎日正常に取得できています」と確認できても、それだけで本番復旧が保証されるわけではありません。必要なのは、障害が起きたときに、必要な時点まで戻して業務を再開できることです。
私は、本番稼働後の運用フェーズで、バックアップから本番環境を実際に戻した経験があります。バッチ処理後のデータ状態に問題が発生し、バッチ実行前の状態へ戻す必要がありました。
修正パッチが重なり、どのデータを正しい状態と考えるべきか判断しづらくなっていたため、業務リーダーから「バッチ実行前まで戻してほしい」という要望が出ました。
本番データを過去時点へ戻せば、その後の変更は失われます。復旧後にはバッチをもう一度実行する必要もあり、基盤担当だけで「戻します」と判断する話ではありません。
要望を受け、PLまで参加したリリース判定会議で復旧方針を判断しました。作業は5月の連休期間中で通常日より時間的な余裕があり、バッチを再実行する時間も含めて考えたうえで、復旧ポイントをバッチ実行前に決めました。
テスト環境では事前にリストア試験を実施していました。それでも、本番環境をEC2／EBSのスナップショットから実際に戻す作業は非常に緊張しました。試験で成功していることと、本番で失敗できないことは別です。
復旧後は、スナップショットが戻ったことだけを見て終わりにはしません。業務側が持っていた確認SQLを使い、データ件数や内容が想定した状態へ戻っていることを確認しました。その確認が終わってから、バッチを再実行します。
このバッチ自体に約10時間かかりました。スナップショットの復旧、データ確認、バッチ再実行までを終え、次の業務開始に間に合わせる必要があり、結果として徹夜での復旧作業になりました。
この経験から、バックアップ設計で重要なのは、「コピーを持っているか」ではなく、「どこへ戻し、正しく戻ったことをどう確認し、そこから業務を再開するまで何時間かかるか」だと強く感じました。
本番復旧では、技術的に戻せることと、実際に戻すと判断できることも別です。復旧ポイント、失われるデータ、再処理に必要な時間を業務側やプロジェクト責任者と共有し、合意したうえで進める必要があります。
バックアップ取得は技術です。復旧は業務再開まで含めた設計です。
図 本番環境をバッチ実行前へ戻し、業務再開するまでの復旧フロ
可用性は「サーバーを2台にする」だけでは成立しない
システムを止まりにくくするために、Webサーバーを2台にする、DBをクラスタ化する、ロードバランサーを二重化するといった冗長化を行います。個別の機器を二重化すれば、システム全体の可用性が自動的に決まるわけではありません。
例えば利用者のオンライン処理が、FW、LB、Web/AP、DBという経路を通る場合、Web/APだけを二重化しても、別の場所にSPOFが残れば、そこがサービス全体の可用性を左右します。
私が担当した大規模システムでは、RFPで求められたSLAやRTOを踏まえて、業務ごとに冗長化レベルを変えていました。
エンドユーザーが直接利用するオンライン系では、長時間の停止を許容できないため、FW、LB、Web/APなど主要な経路を冗長化し、DBも共有ディスク型のHA構成などを使って、短時間で切り替えられる構成にしました。
同じシステム内でも、バックオフィス系、運用管理系、参照系の一部は求められる復旧時間に余裕がありました。こうした系統は常時二重化せず、共通予備機を用意して、障害時に手動で切り替える設計にしたこともあります。
共通予備機への切替手順は基盤結合試験の段階で作成し、システムテストの冗長化試験でも、その手順を使って実際に切替を確認しました。
本番では、ファイルサーバーとして利用していたWindows Serverがダウンし、実際に共通予備機へ切り替えたこともあります。可用性設計では冗長構成を作るだけでなく、想定した時間内に切り替えられることを試験し、その手順を本番で使える状態にしておく必要があります。
すべてを同じ可用性レベルにすると、構築費だけでなく、監視、切替試験、パッチ適用などの運用負荷も増えます。求められるサービスレベルが違うのであれば、構成も変えるべきです。
AWSでも考え方は同じです。短時間で復旧する必要がないシステムなら、常時HA構成にせず、AMIなどから再構築する方法も選べます。逆に短時間の切替が必要なオンライン系では、障害時にどの単位で切り替えるかまで設計しておく必要があります。
「二重化できるか」ではなく、「この業務は何分止められるのか」から構成を決める。 可用性設計は、求められるサービスレベルを現実的なコストと運用で実現する仕事です。
Auto Scalingのように障害時の復旧を自動化する仕組みでも、インスタンスがどの条件で置き換えられ、その結果として監視やジョブ、アプリケーションにどのような影響が出るかまで設計しておく必要があります。
実際にAuto Scalingによる想定外のインスタンス置き換えを経験した事例は、以下の記事で紹介しています。
障害時はアプリ・DB・ネットワークと並行して切り分ける
システム障害では、最初から原因が分かっていることはほとんどありません。
私が経験した障害で、業務画面では「印刷終了」と表示されているのに、プリンターから帳票が出てこないことがありました。
利用者から見えるのは「印刷できない」という一つの事象です。調査する側から見ると、アプリケーションの不具合、APサーバーの処理、印刷キュー、CUPS、lpr、ネットワーク、プリンター本体など、多くの原因候補があります。
実際には、アプリケーション側ではlprが正常終了したことで「印刷済み」と判定していましたが、その後の処理で印刷キューが消失し、帳票がプリンターまで届いていませんでした。
このような障害では、「サーバーは正常です」「ネットワークには問題ありません」と各担当が自分の領域だけを確認しても解決しません。
実際の切り分けでは、利用者が操作した時刻を基準に、アプリケーションログ、APサーバー上の処理、印刷キュー、ネットワーク側の記録などを突き合わせます。どの処理までは正常に到達し、どこから先へ進んでいないのかを順に確定させ、原因となる領域を絞っていきます。
大規模システムでは、AP、DB、ネットワーク、基盤など複数のチームが並行して調査します。基盤担当には、自分の担当範囲を調べるだけでなく、どの情報を他チームと突き合わせれば処理全体を追えるのかを考える役割もあります。
この障害の詳細な切り分けは、以下の記事で整理しています。
クラウドでも本質は変わらないが、複雑さの場所は変わる
オンプレミスからAWSへ移行すると、扱う製品やサービスは変わります。基盤として考える設計課題そのものは、大きく変わりません。
設計課題オンプレミスAWSコンピュート物理／仮想サーバーEC2など可用性HA・クラスタMulti-AZなど監視JP1などCloudWatchなどバックアップバックアップ製品AWS Backup、スナップショットなど容量サーバー／ストレージ増強サービスごとのリソース変更
CPUやメモリをどの程度用意するか、どこまで冗長化するか、何を監視するか、どうバックアップして復旧するかという設計課題は、クラウドになっても残ります。
変わるのは、複雑さの場所です。オンプレミスでは、物理サーバー、配線、SAN、ストレージ機器、ファームウェア、ハードウェア障害なども設計・管理対象でした。AWSでは、その多くをAWS側が担当します。
利用者側では代わりに、AZ、サービスごとの仕様や制約、IAM、クォータ、サービス間依存、責任分界、従量課金などを理解する必要があります。
私が経験したAWSへのクラウドリフトでも、この違いによる大きな手戻りがありました。
オンプレミスでは、同一データセンター内で低レイテンシな共有ストレージを使った構成を採用していました。AWSではMulti-AZを前提に構成を検討しましたが、設計段階からWeb/APとDBが異なるAZに配置された場合のレイテンシーには懸念がありました。
PoCでは、費用上の制約から本番相当のMulti-AZ構成まで用意することが難しく、まだ本番相当データも準備できていませんでした。そのため、性能評価の一部を机上で進めました。
その後、本番相当の環境を構築し、本番相当量のデータで実際の業務処理を流したところ、特定の業務で性能要件を満たせないことが分かりました。Web/APとDBが異なるAZに配置されると、1回ごとの差は小さくても、DBアクセスを繰り返す処理ではAZ間の往復が処理回数分だけ積み上がります。机上では許容できると見ていた差が、実際の業務処理では無視できませんでした。
アプリケーション、AP基盤、DB、AWS基盤などの関係チームが集まり、本番相当データで発生した事象を調査しました。最終的には、通常時はWeb/APとDBを同じAZ側へ寄せ、AZ障害時には関連するコンポーネントをもう一方のAZへまとめて切り替える考え方へ設計を変更しました。
図 Multi-AZ構成でWeb/APとDBの配置・切替単位を見直したイメージ
個々のサーバーやDBを別々に切り替えるのではなく、業務処理を成立させる単位で配置と切替を考える必要がありました。基本設計まで戻る大きな手戻りです。
この構成では、RDSがフェイルオーバーしてプライマリが反対側のAZへ移ると、Web/APとDBが再びAZをまたぐ可能性があります。その場合のDB側の可用性設計や性能影響については、DBAの記事で別の視点から扱っています。
振り返れば、PoCで本番相当条件を再現できない事情はありました。それでも性能リスク自体は認識していたため、検証できなかったことを理由に机上評価で進めるのではなく、最初からAZ間の往復を減らす構成を基本案とする判断もありました。
そして、この経験には既視感がありました。
十数年前、5TPSのバッチ処理でも、机上のスペックだけでは分からず、実機で実際の処理を流したことで問題が表面化しました。AWSになってハードウェアの持ち方は変わりましたが、本番相当のデータと業務を載せなければ分からない性能問題があるという点は変わりませんでした。
クラウドだから基盤設計が簡単になるわけではありません。物理機器の複雑さが、サービス、設定、AZ、制約、責任分界の複雑さへ移ると考えた方が、実態に近いと思います。
クラウドリフトでは、PoCで何を確認し、何を確認できなかったのかを明確にしておかないと、後工程で大きな手戻りにつながります。クラウド移行でPoC不足が問題になる理由は、以下の記事で詳しく整理しています。
RDS for Oracleでオンプレミスと運用や設計がどう変わるかについては、こちらで詳しく扱っています。
クラウドではコストも設計対象になる
オンプレミスでもコスト設計は必要ですが、クラウドでは選択するリソースやサービスが継続的な利用料へ直接反映されます。性能や可用性と同じように、コストも基盤設計のパラメータとして扱う必要があります。
私が経験したAWS移行では、Oracleのエディション構成も大きな論点になりました。
オンプレミスでは多くの業務をEnterprise Edition前提で運用し、Partitioningオプションも利用していました。同じ構成をAWSへそのまま持ち込むと、案件全体としてコストインパクトが大きくなりました。
業務系統ごとにDBを分け、Partitioningを必要とする処理を持つDBだけをEnterprise Edition側へ残し、それ以外はStandard Editionへ載せる構成に変更しました。Standard Edition側へ移せるかどうかは、機能だけでなく必要なCPU性能や処理量も確認して判断しました。
技術的に一つの構成へまとめられるかだけでなく、その構成を継続して維持する費用まで含めて判断したということです。ストレージ性能でも同じことがありました。高いProvisioned IOPSを常時確保すればピーク時の性能は安定しますが、利用料も大きくなります。
特定業務のピーク時に必要な性能と通常時の負荷を分け、通常時はバーストも利用できるよう監視やキャパシティ管理を見直しました。
稼働後も、CPU、I/O、ストレージ、業務量、AWS利用料などを毎月確認し、必要なキャパシティを調整しました。予約や割引の仕組みも含め、翌年度にどの程度のリソースを確保するかを考えます。
余裕を削りすぎれば性能不足になり、持たせすぎれば利用料が増えます。性能、将来の業務量、契約期間、割引制度を組み合わせながら調整する作業は、実際にはパズルに近いものでした。
クラウドでは、一度構築して終わるのではなく、必要なサービスレベルを維持しながら、リソースと費用を継続的に見直すことも基盤エンジニアの仕事になります。
システム基盤エンジニアは複数領域をつなぐ
ここまで紹介した事例は、それぞれ別の技術の話に見えます。
サイジングでは、サーバー性能だけでなくアプリケーションのDBアクセス方式が性能を左右しました。
バックアップでは、スナップショットを戻す技術だけでなく、業務側と復旧ポイントを合意する必要がありました。
可用性では、一台のサーバーではなく、利用者から処理先までのサービス経路を見て冗長化レベルを決めました。
AWSのMulti-AZでも、AP、DB、クラウド基盤を個別に見れば成立していた設計が、本番相当の業務を載せたときにはシステム全体として性能要件を満たしませんでした。
私自身、サーバー／インフラ、ネットワーク、Oracle DBA、AWSへのクラウド移行、基盤統括など、複数の立場を経験してきました。個別技術については、それぞれの領域を専門に担当しているエンジニアの方が詳しい場面も多くあります。
基盤全体を見る立場で重要だったのは、個別製品をすべて深く知ることではありません。この変更がどこへ影響するのか、他チームの設計と矛盾していないか、実際の業務を載せても成立するか、障害時に誰が何をするのか、運用開始後も維持できるのかを横断して確認することでした。
システム基盤エンジニアの価値は、複数の技術領域をつなぎ、システム全体として成立させることにあります。
まとめ｜基盤エンジニアはシステムを整え、保ち、戻す
システム基盤・クラウドエンジニアの仕事は、単にサーバーやAWS環境を作ることではありません。
この記事では、その役割を「整える、保つ、戻す」という3つに分けて説明しました。
整えるのは、アプリケーションが動くためのCPU、メモリ、ストレージ、OS、本番・試験環境、共通設定、クラウド構成などです。構築できることではなく、性能や運用まで含めて使える状態へ持っていきます。
保つためには、監視、ログ、ジョブ、キャパシティ管理、可用性、コスト管理が必要です。冗長構成を設計することも、正常なサービスを維持するための「保つ」に含まれます。
戻すのは、実際に障害が発生した後です。冗長系への切替、バックアップからの復旧、再構築、障害切り分けを行い、業務を再開できる状態へ戻します。冗長化は「保つ」ために設計し、障害時に実際に切り替える行為は「戻す」に当たります。
オンプレミスからクラウドへ変われば、扱う技術は変わります。物理サーバーを直接扱う機会は減り、AWSのサービスや設定を扱う機会は増えました。
それでも、基盤エンジニアが考えるべきことの本質は大きく変わりません。
必要な環境を整え、安定して使える状態を保ち、問題が起きたら業務を戻す。
それが、システム基盤・クラウドエンジニアの仕事です。
関連記事
システム開発では、システム基盤エンジニアだけで仕事が完結することはありません。アプリケーション、データベース、ネットワークなど、それぞれの担当が連携してシステム全体を作ります。
アプリケーションエンジニアの仕事
業務要件を仕様へ落とし込み、設計・実装・テスト・障害対応まで担当するアプリケーションエンジニアの仕事を解説しています。
データベースエンジニア（DBA）の仕事
データベースを安定して利用できるよう、設計、性能管理、バックアップ、障害対応などを担当するDBAの仕事を解説しています。
ネットワークエンジニアの仕事
通信経路、ルーティング、通信制御、冗長化、外部ネットワーク接続、障害時の切り分けなど、ネットワークエンジニアの仕事を解説しています。
SEの職種全体と、それぞれの役割の違いについては、次の記事で整理しています。
コメント