はじめまして。株式会社PRUMでエンジニアをしているひとみです。
日々、プログラミング学習や実務の中で、つまずきやすいポイントや
考え方を整理して発信しています。
PRUMについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
「クラウドだから大丈夫」は危険です ― 新人エンジニアがやりがちな“信頼性の勘違い”
はじめに
新人のとき、こんなこと思ったことないですか？
- クラウドだから勝手に冗長化されてる
- インフラは誰かがいい感じにやってくれてる
- とりあえず動いてるからOK
でもこれ、結構危ない考え方です。
実際の現場では、設計していないことが原因でシステムが落ちるということが普通に起きます。
「なんで本番だけ落ちるの？」の正体
よくあるパターンです。
- ローカルでは動く
- テストでも問題ない
- なのに本番で落ちる
このとき、多くの新人はこう考えます。
コードが悪いのかな？
もちろんコードが原因のこともあります。
ただ、それだけではありません。
原因の一つに、実行環境の前提（ハードウェアやリソース制約など）を理解していないことがあります。
ありがちなミス①：メモリを意識していない
例えばこんなケースです。
- ローカル → メモリ余裕
- 本番 → メモリ不足
これだけでシステムは落ちることがあります。
アプリケーションは基本的にメモリ上で動作するため、
メモリが不足すると処理が止まったり、プロセスが終了したりします。
つまり、どのデータをどこに置くかによって性能と安定性は大きく変わります。
ありがちなミス②：ストレージは壊れる前提がない
例えばDBの保存です。
「保存しているから安心」と考えがちですが、これは危険です。
現実には次のようなことが起きます。
- ディスクは故障する
- いつ壊れるかは予測できない
クラウドではマネージドサービスによって冗長化が提供されていることが多いですが、
重要なのはどこまでがサービスの保証で、どこからが設計の責任かを理解することです。
その前提で、壊れたときの動きをあらかじめ決めておく必要があります。
ありがちなミス③：CPUを“速さ”だけで見ている
CPUは「クロックが高い＝速い」と考えられがちですが、それだけではありません。
- コア数：同時に処理できる数
- GPU：特定の処理に特化した計算
例えば、同時アクセスが増えるとコア数の影響が大きくなります。
つまり、どのような処理をさせるかによって最適な構成は変わります。
クラウドの正体をちゃんと理解する
クラウドは魔法のように見えますが、実際にはそうではありません。
ハードウェアを抽象化し、仮想化や分散によって扱いやすくしている仕組みです。
仮想化によって、1台のサーバーを複数の環境として利用できます。
また、複数のサーバーやデータセンターに分散することで、可用性や耐障害性が高められています。
ただし、CPU・メモリ・ネットワークといった物理的な制約は必ず存在します。
信頼性は「気合い」ではなく「設計」
システムは必ず壊れます。
そのため重要なのは、壊れないことではなく、
壊れたときにどう振る舞うかを設計することです。
おわりに
ハードウェアやインフラの話は地味に感じるかもしれません。
しかし、これを理解することで、
- なぜ落ちるのか
- なぜ遅いのか
- なぜその構成なのか
が見えるようになります。
そして最も重要なのは、
「動く」ではなく「安心して動く」システムを作ることです。
ここにエンジニアとしての差が出てきます。
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト