IT業界で使いそうな言葉 その3

今回もやってまいりました。「IT業界で使いそうな言葉その3」でございます。嬉しい事に、最近は検索から来る方がいらっしゃるみたいなんです。

 

検索ワードは、ほとんどがIT用語に関連するワードのようなので、今後はこのシリーズを、他よりも多めに投稿していこうと思ってます!

 

ちなみにご紹介させていただいている用語は、私が経験した商談やプロジェクトで、聞いた実体験を基にチョイスしてますので、ある意味ノンフィクション(?)です。一気に覚えず、使いそうな言葉から少しづつ覚えていきましょう!

 

今回のテーマは「インフラ」についてよく出てきそうなものをピックアップいたしました!

インフラ

まずはここから。インフラとはインフラストラクチャを短くしたもので「産業基盤」って意味なんです。

 

なのでITの場合は、サーバーやら通信機器、回線、施設などなど、システムを動かすための「基礎の部分」を指します。電車で表現すると、電車を動かすための「線路とか電線」みたいなもんです。

 

「インフラエンジニア」はサーバーやネットワークの技術者を指すことが多いです。ただOSやソフトウェアがないとサーバーは稼働できないので、OSやソフトウェアもインフラの範囲に含まれます。

※もっと簡単に表現する場合

 

長い!3行で説明してくれ!

 
 

1行目:すごく広い部屋に
2行目:機器がいっぱいならんでる
3行目:これがまさにインフラ環境

 
 

オンプレミス 

いわゆるクラウドの反対語で、基本「オンプレ」って言う人が多いです。クラウドはインターネットの先にあるインフラ環境を借りてますんで、自前でサーバーや通信機器を持つ必要がありません。

 

それに対しオンプレの場合は、サーバーや設置場所を自前で用意し、管理も自前で行う事を指します。

 

では何故自前で持たなければいけないのでしょう?代表的な例をあげますと、金融系などは大きなトラブルが起きると、社会を巻き込んだ大事件になりますので、クラウドを利用する事に高いハードルがあるんです。

 

この業界のシステム環境は、インターネットの接続ができないのはもちろんの事、物理的にも厳重にクローズされた環境で取り扱ってます。

 

つまり乱暴な言い方をすると、クラウド環境を信用せず、自分の身は自分の力で守っている訳です。

 

もし何かあったら、クラウドサービスの業者ではなく、クラウドサービスを利用していた企業が責任を問われますので、便利や効率を考える前に、僅かなリスクも見逃さず、死守する事を考えなければいけないんです。

※中年IT営業の飲み会での一コマ

 

中年IT営業A:ぶっちゃけ、クラウド化でいろいろ便利にはなったけど、オンプレ全盛期の頃の方が儲かってた気がしない?

 
 

中年IT営業B:正味な話、その頃って機器も簡単に売れたし、更に導入作業だけでも結構お金取れたよね。億単位の大型案件も結構あったしなぁ・・

 

スケールアップ

これ類似用語があるのでちょっと注意です。スケールアップはCPUやメモリを増設してサーバーの性能をあげる事です。単純に意味としてはこれだけで、難しい事はありません。

スケールアップは、サーバー1台だけを増強していくので、上限値がありますので注意しましょう。

※カンフー映画風 利用例

 

メモリをたった1GBでいい・・増強してスケールアップしたい。しかし本当にそれは正しいのか・・俺には解らない。

 
 

ブルースリー先生:考えるな、感じろ!

 

 

スケールアウト

スケールアップに言葉が似てるので間違えやすいのですが、こちらはサーバーの台数を増やしてシステムの性能をあげる事を指します。

 

サーバのスペックを上げるのではなく、台数だけ増やしていく感じですね。

 

例えば、2台で分散させて稼働させてたサーバーを、1台増やして3台で分散させたりするイメージです。

 

こちらの場合、スケールアップの様に上限値を意識する必要はありませんが、あらかじめ、スケールアウト可能な設計をする必要があります。

 

その為、比較的規模の大きなシステムなどで使われやすいのが特徴です。

※Zガンダム風 利用例

 

アクセスが多すぎてもうサーバー限界です!はやくスケールアウトを!

 
 

クワトロ大尉:まだだ!まだ終わらんよ!

 

冗長化

サーバーやネットワーク機器が故障しても業務が停止しない様に、まったく同じ設定の予備を用意しておき、不慮の事故や故障に備える事です。

 

ざっくり言うと予備電源みたいなもんです。

 

余談ですが、冗長化を「リダンダンシー」なんて表現を使ってくる強者もたまにいますのでご注意を。

フェイルオーバー

こちらは冗長化とセットになる話です。

 

サーバーなどを冗長化する場合、よくあるやり方が、本番用(アクティブ)と待機用(スタンバイ)のサーバーをそれぞれ用意します。

 

本番用と待機用のサーバーは、互いに常にちゃんと稼働をしているか確認を行っています。

 

もし本番用から確認の返事が来なくなったら、自動的に待機用が本番用に変わるような仕組みになってます。

 

この仕組みを使って、待機用が本番用に切り替わる事を「フェイルオーバー」っていいます。こうすれば障害があってもすぐに業務ができるようになりますよね。

フェイルバック

フェイルオーバーは、本番用のサーバーに障害が発生したら。待機用のサーバーが自動的に本番用になるというお話をさせていただきました。

 

フェイルバックはもともと使われてた本番を復活させます。

 

そして待機用から本番用に切り替わったサーバーを「待機用」に戻して、元通りの環境に戻します。これをフェイルバックっていいます。

 

冷蔵庫の俺のプリン食べただろ?

 
 

食べられる事を想定して冗長化すべきです。次回から2個買って来て下さい

 

ディザスタリカバリ

ざっくり「災害時の復旧」って意味です。頭文字をとって、DR(ディーアール)なんて呼ばれ方が一番多いと思います。

 

DRは9・11事件をきっかけに改めて必要だと認識されました。

 

この影響でデータを完全に失い、事業を継続できなくなり、倒産した企業も多かったそうです。

 

日本も比較的災害が多い国ですし、東京もいつか直下型地震がくるかも?なんて話があります。

 

このような災害が発生して、都市が壊滅状態になったとしても、遠隔地にあらかじめ同じシステムや、重要なデータを設置しておき事業を復旧できる仕組みを「ディザスタリカバリ」といいます。

 

簡単に言ってしまえば、レベルの高いバックアップな訳ですが、大事なのはデータを保存する事ではなく「いかに素早く復旧して事業を再開できる様にするか」という部分です。

 

例えば、東京とまったく同じシステムを大阪に用意しておきます。

 

こうすると、もし東京に首都直下型地震が来て、都市が壊滅したとしても、大阪で用意してあるシステムを起動すれば事業が再開できるわけです。

 

DR関連で、RTOとRPOという用語があります。これはDRの話になると、セットで出てきやすい用語なので、次の項目で説明します。

RPO

DRの話がでたときにセットで出てくるのが、RPOなんです。RPOとは「目標復旧地点」という意味です。

 

何だか解りずらい日本語ですが、実は簡単な話で「どれくらい前までのデータを常にリカバリできる様にしておくか?」の「決め」ですね。

 

例えばRPOを「1日前」と決めたら、いつデータが壊れても1日前までの状態には戻せる様な設計でシステムを作ります。

 

数秒とか数時間とか直近の時間にするべきでは?

 

と思われるかもしれませんが、早くすればするほどコストは上がっていきますので、業務やコストバランスを考えながら決めていくのが一般的です。

RTO

これもDRの話が出てきたときにセットになって出てきます。

 

RTOは「目標復旧時間」という意味で「業務ができるまで復旧するのにどれくらい時間がかかるか?」の「想定時間」です。

 

例えば障害が発生してから、予備の環境に切り替えるのが1時間かかるとしたら、この場合RTOは1時間となります。

 

もう1つ別な例を挙げると、バックアップしていた膨大なデータを3日かけて戻すとしたら、この場合はRTOが3日となります。

 

気を付けなければいけないのは、「RPOが1日前でRTOが3日」になっちゃうと「1日前までのデータをリカバリできるのに、結局戻すのに3日かかる」話になってしまうので、設定したRPO(復旧地点)よりも早くRTO(復旧時間)を計画する事がポイントです。

 

最近はDR訓練っていうのがあるんでしょ?

 
 

訓練とはいえ本番環境でやるから、俺の寿命がストレスでマッハ

 

番外編 ※再発防止策

再発防止策って障害対応の経験がある人には、おなじみの言葉ですよね。

 

障害の原因がオペミスだった場合は、再発防止策で「これからはダブルチェックを実施します!」みたいな感じになると思います。

 

でも、それでも間違う事ってあるんですよ(人間だもの)最近のIT業界めっちゃ忙しいし大変だし。

 

さて、じゃあダブルチェックがだめなら、次の再発防止策は?→ここでたまに出てくるのが「トリプルチェック」です。

 

トリプルチェックする事で、うまくいくのでしょうか?実際、私はこれで解決した例をみた事がないです。

 

ツイッターでちょっと前にバズってましたが、結果的にこうなってしまい状況が悪化する例をよく見ました。

 

 

自分の経験を振り返ってみると、販売元や販売先のどちらかが、やたらテンプレ化しすぎたり、一方的に責めたり、一方的に話を聞きすぎたりすると、有益でない無茶な対策を実施する事になり、こういう結果になりやすいのかな?なんて思いました。

 

本当の改善案(再発防止策)は双方で情報を共有して折り合いをつけ、その上で調整をしないと良い結果にならないかもしれませんね。

どうでもいい余談

最後に再発防止策について、どうでもいい余談です!

 

私がよく行く焼き肉屋は、過去他のチェーン店でO157や食中毒が出た事があります(※私はまったく気にせず通ってます)

 

こういう事があると、再発防止策として、全店舗のルール変更が行われ、トングの種類がどんどん増えていく傾向がある様です。

 

直近では「焼き用トング」の他に「生肉つかみ用トング」が追加されました。

 

もし次回も類似の事象が発生してしまったら、再発防止策で、また新しい用途のトングが増えるのでしょうか。

 

今後の動向が気になるところです。

フォロー待ってます!
シェア大歓迎!

コメントを残す

メールアドレスが公開されることはありません。