はてなキーワード: サーバーラックとは
システムを内製するので、かろうじてプログラムをかじったことのある自分が抜擢。
泣きながら障害を起こしながらも、2~3年くらい安定稼働させた。
DCに設置された連携先のサーバーが片系死んでるのお客さんに黙ってて
閉域とはいえ、サポートとっくに切れてるしやべぇからこっちも直せ、と。
設計書もソースもなかったが、バイナリからソースコードが取り出すことができた。
さぁ切替だと思った矢先、事件が起こる。
同僚の嫁に、上司が手を出そうとしたのがばれ、上司が逆切れした。
上司と一緒は嫌だなぁ、と一緒に飛ぶことに。
サーバーはここにラッキングしてあるで、取り出して持っていってください。
手順はまとめたんで、この通りやってくれれば動きますよ。と上司に伝える。
異動後の部署で仕事をこなして1年経ったか、引継ぎの子から電話。
「連携先のサーバーが障害起こしてて、どこ見たらいいですか?」と。
あれ、障害起こすと省庁に呼ばれるやつじゃない?と思いつつ
サーバーのxxにログファイル出てない?と薄い記憶を頼りに自分が作ったプログラムをおもいだす。
え?フォルダ消えたの?Dドライブの直下って何ある?ン?ピンとこないフォルダ群。
悩む。突き放すこともできるが、呑みに行ったこともあるしなぁ…。いや、会社が危ない。
一旦電話を切って空を見つつ俺考えてますよアピールしていると、ふと気になることが。
さっきのフォルダ構成ってどっかーで見たよねー?引継ぎの子に電話。
サーバーラックにxxxxってテプラの張ってあるサーバー2台、ある?無いよね?
「…えー、っとあります。」
自分が作ったサーバーはあの時のまま、DCに運ばれるのを待っていた。
引継ぎの子が見ていたのは、1年前切り替えようとした古いサーバーで、延命というか放置されていた。
古いほうの復旧方法は流石に知らないので、そりゃしらんわーとお断り。
片系壊れてて1台で動いてるサーバーをエイヤで再起動するらしい。
その後連絡は無いので、復旧はしたんだろう。会社は今も存続している。
https://news.yahoo.co.jp/articles/6ed4869fdca7cf63f81c8a3dc5870869be0debeb
いまではAWS、Azureのようなパブリッククラウド一辺倒時代だけど本当にいいの?
費用は高いし、サービスは落ちるし、設定は複雑だし、好んで使いたがるなんてただの変態だよね。
AWS使える = 高度な知識? いや、、、単なる「もはや使い方を知っているオペレーター」でしかないよね。
オンプレでも落ちるだろ?って?
→ 規模の大きさにもよるけど、サーバーラック数本程度の管理ならAWSほどガンガン障害起きないし、自分たちで手が出せない感は無いしなぁ。
→ まぁ、そうだけどさ。銀の弾丸は無いさ。
そこんとこ詳しく。メタップスとか?
Waf なんて書くな! WAF とかけ!
うっせーな。クラウドベンダーの独自 API なんか使いたくねーんだよ。オラクルじゃあるまいし。
まぁ、それは認める。でもさ、select や create とかのDML/DDL は CRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータにアクセスできなくなるかもよ?
そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前までは Flash と DoJa のアプリを作ることがフロントエンド開発者でしたよ?一方データベースや OS の方は、ここ三十年ぐらい Unix と RDB が鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかで C言語開発者はバリバリっすよ。例えば、クラウドフレアなんか CDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤの根本技術の改善であって、私はそこにプロフェッショナル性を見出しますがね。
わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えている C/C++ でサーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンスを必要とするなら Rust、または GC があるけど Go言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか?いい加減にしろ。
そうだね~。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態の我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの?時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニアを採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。
誰が Next で SSR なんてするか!あれは SEO が必要な場合に限る。そもそも SSR なんて危険だからまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザとクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラにインデックスされるページで SPA をやろうとするやつはセンスないで。
すいませんでした。本当にすいません。
ん? AWS SQS だとパフォーマンスに問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん?ログ収集は GKE みたいに ログに出したら Fluentd で収集してくれる時代になんでグチグチ言われないといけないの?
ハア?インメモリのデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。
これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんて Kubernetes で展開したら運用までしないといけないじゃん。メンドクサ。
いや、J1ビザをとってアメリカに留学したことあるよ。あと、「世界でもっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん。馬鹿にしてるのか?
Web系は動けばよいで、セキュリティー忘れて、大問題になった、例が過去どれだけあるかを説明しないといけないのは、とっても手間だよね。
あと、Web系でもベンチマークは必要。マシン2台と1台の差はあまりないかもしれないけど、200台と100台の差は結構あるし。
電気代や、サーバーラック代、メンテナンス費用、などのランニングコストに効いてくる。
ロードバランサーも高い物を検討しないといけなくなってくる。
システムから見れば、Web系でもベンチマークをしてトータルソリューションのコストダウンすることは非常に重要。
というのを説明しないと行けないのは、とっても手間だよね。
わかります。