はてなキーワード: サーバとは
原発の周囲をDC(データセンター)で囲めばいろいろな問題が一挙に解決できると思った。
もし原発が爆発したら、DCにおいてある超高価なサーバも消滅する。
ただし、もしメルトダウンして原発が吹き飛べば、数百億円、数千億円規模のサーバも消える。
原発は安全だといっても、住んでいないから言える他人事だろうと言う人もこれなら納得するだろう。
これを北海道や東北の寒冷地でやれば、冷却コストが下がる寒冷地DCができる。
昔、「営業や社長の『紙芝居でいいから』『POCでいいから』という言葉を鵜呑みにするな」と教えられた。
その言葉通り、さっと動いて見せられるものを作ると、それが客先でデモされ、「ここまで動いてるんだから、工数かからないで完成できるよね?」となって、「工数かけたんだから」と最初に作ったものがベースになり、作り直す機会もなく会社の屋台骨に育っていく。
Webサービスでは、個々の端末で実行されるフロントサイドはともかく、サーバサイドはランダムに並行して到着する、かかる時間が長短まちまちのリクエストを捌くことになるわけで。
最近相談を受けたプロダクトは、あまりに全てが独自に育ちすぎていて、合理的に改善する(改修によって見込める利益と改修にかかる費用が全くバランスしない。100年くらいかければペイする?)には手の施しようがない状態になっていた。
今の「生成 AI で迅速にローンチ」を見ていて、サーバサイドの知識もろくになく、その基礎の上に積み上げていって大丈夫か? と思う。
かと言って、最初からガチガチに設計しろと言っているわけじゃない。
移行が必要になったらどうするかの見通しを立てておく。
データも。
処理も。
アーキテクチャも。
ということ。
スモールスタートと言っても、手遅れになるクリティカルなポイントはあらかじめ見通しを立てておく必要はない、というものではないと思っている。
エッジサーバしらんの?
サービス向上のため。 通信速度は距離が短いほうが有利で、ユーザが多い場所にデータセンタを設置する強い動機がある。
インターネット上を流れる膨大なデータをさばくために情報のクローンを世界中の拠点 (データセンタ) に分散させる CDN という仕組みがあるんだが、拠点が近くにないような地域では CDN の恩恵を得にくい。
特に動画は容量が大きいし安定した通信速度が必要 (動画再生より通信速度が遅いと途切れてしまい視聴体験を損なう) なので大手動画配信サービスは都市部の住宅地に積極的に CDN のエッジサーバを置いてる。
データセンタがどのようなデータを扱ってるのかは場合によるけどあえて住宅地の中心にデータセンタを置こうとしている場合は CDN の拠点の可能性が高いので地元の人に恩恵はあるよ。
消費税率の変更と聞くと、多くの人はレジの数字を一つ打ちかえるだけの簡単な作業を思い浮かべるかもしれない。しかし、実際のレジは、店頭で「ピッ」と音を立てる箱にとどまらず、その背後に広がる巨大な神経網の末端にすぎない。バーコードを読み取った瞬間、その情報は在庫管理システムに流れ、発注システムや本部サーバ、会計システム、ポイントや電子マネーの管理、さらにはネット通販サイトといった別々の世界へと枝分かれしていく。税率を変えるとは、このすべての経路で数字の意味が変わる、ということでもあるのだ。
たとえば税率が一時的にゼロになるとき、単に「0%で計算し直せばいい」という話では終わらない。レシートにどう表示するのか、軽減税率との区別をどう付けるのか、締め処理や決算書のどこで「課税」と「非課税」を線引きするのか、そのたびにプログラムの分岐を見直し、帳票のレイアウトを調整し、テストケースを積み上げていく必要がある。しかも、その作業は一社、一店舗だけで完結しない。全国に散らばる何千、何万台ものレジが、営業を続けながら同じタイミングでミスなく振る舞えるように、夜間や休業日にアップデートが配られ、店長と本部が確認し、現場のスタッフが新しい操作に慣れていくまでの時間が必要になる。
だから、「技術的にはそれほど難しくないのに、なぜ時間がかかるのか」という問いに対しては、こう答えることになるだろう。難しいのはコードそのものよりも、「社会全体の時計を、一斉に一分だけ進め直す」ような段取りなのだと。制度の詳細が固まるのを待ち、関係するすべてのシステムを洗い出し、ミスが許されないお金と税の世界で慎重にテストを重ねる。その結果として、カウンター越しの小さなレジが、何事もなかったかのように新しい税率で動き出す。その見えない準備の厚みが、「レジのシステム変更に時間がかかる理由」の正体なのだ。
どっかのサーバが落ちてる。