【地獄からの生還】1000人規模の社内システムで経験したインフラ地獄と、5年後の完璧なリプレースで得た教訓

インフラエンジニアとしてキャリアをスタートさせて間もない頃、私は1000人規模の社内システムのサーバー構築を担当しました。

それは、技術的な知識、プロジェクト管理、そして何よりもエンタープライズの現実を叩き込まれた、文字通りの地獄でした。

しかし、その地獄での経験が、5年後の完璧なサーバーリプレースと、その後の安寧な運用を実現する最高の教材となりました。本記事では、その生々しい経験を包み隠さずお話しし、インフラエンジニアの読者の皆さんにとって重要な教訓を共有します。

序章：与えられた「ふんわり提案書」と地獄の幕開け

入社2〜3年目。私に与えられたのは、Oracle RAC（Real Application Clusters）を組むDBサーバーと、Hyper-Vで仮想化するAPサーバーという、当時としては少し「こなれた」構成の提案書だけでした。

今思えば、シンプルな業務システムにOracle RACは過剰でした。複雑な構成はライセンスと運用コストを跳ね上げ、高可用性（HA）のメリットがデメリットを上回ることはありませんでした。

1. 初心者時代の学び：仮想化とHyper-V

APサーバーの仮想化構築は順調に進みました。初めて触るHyper-Vは大変勉強になりました。新しい技術の導入は、インフラエンジニアとしての成長を実感できる瞬間です。

2. 最初の地獄：ブルースクリーンとの一ヶ月戦争

問題はDBサーバーの構築中に起こりました。互換性からOracle 10gを選定し、マニュアル通りにインストールを進めていましたが、何度やっても特定の時点でブルースクリーンに陥るのです。

• 当時の苦悩: 環境を変えても同じ現象が起きるため、ソフトウェア（Oracle）のバグだと確信。しかし、サポート契約の存在を知らなかった私は、成す術もなく1ヶ月間ひたすら再インストールと調査を繰り返しました。
• 解決の糸口: プロジェクトマネージャー（PM）経由でOracleのサポート契約があることが判明。調査の結果、特定のバージョンにおけるOracleの不具合であり、パッチが存在することを知りました。パッチ適用後、インストールは無事に成功しました。

💡 教訓1：エンタープライズ製品のサポート契約は「コスト」ではない
Oracle、SAP、Windows Serverなど、基幹系のエンタープライズ製品を利用する場合、サポート契約は「実質的に必須」の構成要素です。技術的な困難に直面した際は、無駄な調査時間を費やす前に、ベンダーサポートを速やかに活用できる体制（契約）を確認することがプロジェクト遅延を防ぐ鍵です。

3. 第二の地獄：パフォーマンス問題とリソースサイジングの失敗

私がブルースクリーンと格闘している間にプロジェクトは遅延し、DBサーバーがアプリケーションチームに引き渡された直後、深刻なパフォーマンス問題が発覚しました。

私は当時、OSのパフォーマンスモニターしか調べる術を持っていませんでしたが、後にSTATSPACK¹の存在を知り、詳細なボトルネック調査が可能になりました。

• 当時の設計ミス:
  • 以前のプロジェクトで「メモリは今後の成長に合わせて半分くらい残しておくもの」と教わっていたため、インスタンスに割り当てたメモリを控えめにしていました。
  • STATSPACKのレポートを読み解いた結果、インスタンスメモリ（SGA/PGA）が圧倒的に足りないことが判明。

💡 教訓2：リソース割り当ては「成長」より「最適」を優先
DBインスタンスのメモリ割り当てのような変更が容易なリソースは、「将来のために残す」のではなく、最初から最大限近くを割り当てるべきです。その後、STATSPACK/AWR²のキャッシュヒット率やメモリ使用量を見ながら、パフォーマンスの黄金比を目指して調整していくのが正解です。

4. 第三の地獄：根本的なハードウェア選定ミス

メモリ割り当て程度の修正では解決しませんでした。ボトルネックは根本的なハードウェア設計にありました。

ボトルネック	詳細	改善点（次のリプレースで活かした点）
CPU	コア数は多いが周波数が低いCPUを選定。Oracle SE23は最大8コアしか使えないため、周波数の低さが処理性能のボトルネックに。	周波数が高い8コアCPU(16スレッド)を選定。
メモリ	圧倒的に不足。	次回は倍以上を割り当て。
ネットワーク/I/O	インターコネクトとiSCSIストレージ接続が1Gbps。メモリ不足によるキャッシュフュージョンとディスクI/Oの頻発で、帯域が完全に飽和。	10Gbpsネットワークとオールフラッシュストレージを選定。

この状態のまま本番稼働を迎え、地獄のクレーム対応が始まりました。

パフォーマンス地獄からの脱出：1ヶ月間の二重生活

システムが遅すぎてクレームの嵐。遅延の原因は明らかにデータベースでした。私は、日中は通常業務、夜はひたすらパフォーマンスチューニングという二重生活を1ヶ月送りました。

• STATSPACKで遅いSQLを特定し、片っ端からリストアップ。
• 実行計画を調査し、テーブルのフルスキャンが多いことを発見。
• この時はファンクションインデックス⁴などを使ってなんとか切り抜けましたが、後に真の原因が判明しました。
• 真の原因の究明（後の気づき）:
  • 暗黙の型変換：SQLのWHERE句で、数値型の列に対して文字列リテラルを比較しているなど、データベースが自動的に型変換を行うことで、インデックスが使われなくなっていた。
  • 否定句：!=やNOT INのような否定句が多用されていた（これは当時も気付いて対策）。

💡 教訓3：SQLチューニングは「実行計画」と「型」が全て
DB性能問題の9割はSQLにあります。インフラエンジニアでも、インデックスが使われない理由（暗黙の型変換⁵、否定句、関数利用など）を深く理解し、アプリケーションチームにフィードバックできる知識が不可欠です。

この地獄のような1ヶ月のチューニングを経て、システムはなんとか遅いながらも延命することができ、次の5年間の稼働を支えました。

🌸 我が世の春へ：完璧なサーバーリプレース

そして5年後。私はこのシステムのサーバーリプレース案件を、要件定義から設計・構築・テストまですべて主導することができました。

5年間の鬱憤をすべて次の設計にぶつけ、そして「現行と同等の費用で」という制約の中で最高のバランスを取りました。

1. RACからの脱却とライセンスコスト削減

真っ先に廃止したのはOracle RACです。シンプルな業務システムには過剰であり、ライセンスコストの削減が最も大きなメリットでした。

• 新構成: Oracleはシンプルなフェールオーバークラスタ構成に移行。
• 結果: 運用は劇的に楽になり、HAの要件は十分に満たしつつ、ライセンスコストは大幅に削減できました。

2. 過去の失敗を全て潰したハードウェア選定

改善前のボトルネック	改善後の選定	選定理由（全て過去の反省）
CPU周波数が低い	周波数の高い8コア16スレッド	Oracle SE2の制限に合わせた最適解。コア数より単一コアの性能を重視。
メモリが不足	現行の倍以上	キャッシュミスによるI/O頻発を防ぎ、DB性能を最大化。
1Gbps I/OとiSCSI	オールフラッシュストレージと10Gbpsネットワーク	ディスクI/O待ち時間とネットワーク競合を根本的に排除。

結果、これらの選定は見事に機能し、システムは劇的に高速化しました。顧客からは何も言われませんでしたが、「あるべき姿」を取り戻すことができました。

3. 安寧な運用と予防保全の仕組み化

リプレース後の5年間は、本当に静かでした。

• STATSPACKの常時監視: 1時間おきに自動レポートを生成するよう設定し、パフォーマンスの傾向を常に追えるようにしました。これにより、問題が顕在化する前に予兆を掴むことが可能になりました。
• 数少ないクレーム対応: パフォーマンスのクレームがあっても、 「今回も暗黙の型変換かな」 と目星がついており、すぐに解決できました（実際に暗黙の型変換が原因でした）。
• 別件の貢献: データ消失トラブルが発生した際も、インフラ担当としてテスト環境に本番データをリストアし、開発者の調査をサポート。インフラ担当の枠を超えた貢献ができました。（ちなみに原因はユーザーが独自に作っていたAccess操作でした。）

まとめ：インフラエンジニアの仕事とは

10年間にわたるこの顧客との付き合いは、最高の教材であり、最高の成功体験となりました。

最初の5年間	次の5年間	得られた教訓
試練と成長	経験に基づく安寧	失敗から学ぶことの重要性
サポート契約なし	サポート体制確立	ベンダーサポートの活用
過剰なRAC構成	シンプルなHA構成	構成の複雑さはコストとリスク
経験則でメモリ割り当て	STATSPACKで最適化	メトリクスに基づいた設計
地獄のクレーム対応	ほぼノープロブレム	予防保全と監視の仕組み化

最終的に、顧客からは「速くなった」という感謝の言葉は何もありませんでした。しかし、それはシステムがあるべき姿に戻っただけであり、インフラエンジニアとしては最高の褒め言葉だと理解しています。

インフラエンジニアの仕事は、「動いていて当然」という「当たり前」を、静かに、確実に、永続的に提供し続けることです。

1. STATSPACK (スタッツパック): Oracle Databaseのパフォーマンス統計情報を一定間隔で収集・保存し、レポートとして出力するためのツール。Oracle 8i〜10gあたりで主流でした。主にEnterprise Editionで利用可能なAWR（Automatic Workload Repository）のベースとなった機能です。 ↩

2. AWR (Automatic Workload Repository): Oracle Enterprise Editionの有料オプションであるDiagnostics Packに含まれる、STATSPACKの進化版。自動でスナップショットを取得・管理し、STATSPACKよりも多くの情報を提供します。 ↩

3. Oracle SE2 (Standard Edition Two) のコア制限: Oracle Database Standard Edition Two（SE2）は、サーバー搭載可能なソケット数が2つまでに制限されている他、1つのインスタンスで使用可能なCPUスレッド数が最大16までという技術的な制限があります（RAC構成の場合は各サーバー8まで）。そのため、コア数が多くても周波数が低いCPUだと、SE2の制限下で性能が出にくいという問題があります。 ↩

4. ファンクションインデックス: テーブルの列の値ではなく、その列に適用した関数（ファンクション）の結果に基づいて作成されるインデックス。SQL文のWHERE句で関数が使われている場合に、フルスキャンを回避し、インデックスを使用可能にするためのテクニックの一つです。 ↩

5. 暗黙の型変換: SQLで比較を行う際、比較対象のデータ型が異なると、データベースが自動的に一方のデータ型をもう一方に変換すること。例えば、VARCHAR2型の列に対してWHERE column = 123（数値）と書くと、VARCHAR2型の列にTO_NUMBER()関数が適用されたのと同じ状態になり、インデックスが使えなくなる（フルスキャンになる）主要な原因の一つです。 ↩