Notices by 犬吠埼一介⑨わさらー団 (inbosk@wasaradan.m.to), page 156

何、ギットって。

日本語発音「ギットハブ」らしい
このギットの意味が分からないの
すごくもったいないって思うのん
ここがもう取っつきが悪いからね

ある意味でサイボウズみたいな
ものなのかなと想像してますね
会議あるぞって情報を共有する
開発案件の諸々を共有するため
こういう統合環境が作られてる
俺がいたころになかったのはね
設立が２００８年だからだろう

GitHubっていうのか。アクセス
してみた。日本語で書かれてる
オープンソースってことなのか
なかなか素人は観ないだろうな

マストドン日本語メタフォーラム
めっちゃいいじゃないですかこれ
日本語ってところが非常に大きい
はっきりいって英語は読めないし
書けないからこれは助かりますね

そういうことがいいたかったのん

分かりみーそういうことですよね
何だあるのかよかったなと思うわ

今観てるけどギガが足りないので
ぜんぜん表示が遅くて悲しみッス

おおーすでにあるんですねさすが
僕ごときが考えることはあるねー

サービスを負荷分散的に運用する
概念を平易に語れる僕としてもね
多少の権威を感じるってだけです
実際に使えば便利なのかもしれぬ
マストドンのこと相談する掲示板
誰か立て代表でハブに上げるとか
そういう構成にしてもいいかもね
素人がそこに書きに行くのは遠い

サーバが仮想化できるってことは
ブレードサーバに代表されるけど
ハードウェアの制約を無視できる
サービスが重たい花火大会の日は
多重構成で何もない日は一枚だけ
しかしそれも述べたように仮想化
したサーバは霞になるのと違うし
電源やコントローラが壊れたらね
サービスが停止してしまうわけよ
だから結局仮想化することによる
メリットは負荷によりサービスの
強度を調整できることであってね
あとはブレードの何枚目が故障と
いうハードウェア的な脆弱性をね
一定の回避は可能ただし万全では
ないので冗長化がいらないわけは
ないだろうと僕は考えてますよね

サーバが仮想化できるってことは
ブレードサーバに代表されるけど
ハードウェアの制約を無視できる
サービスが重たい花火大会の日は
多重構成で何もない日は一枚だけ
しかしそれも述べたように仮想化
したサーバは霞になるのと違うし
電源やコントローラーが壊れたら
サービスが停止してしまうわけよ
だから結局仮想化することによる
メリットは負荷によりサービスの
強度を調整できることであってね
あとはブレードの何枚目が故障と
いうハードウェア的な脆弱性をね
一定の回避は可能ただし万全では
ないので冗長化がいらないわけは
ないだろうと僕は考えてますよね

基本的にサーバを運用するうえで
サービスが経路として流れる前段
後段その中間地点の複数台構成で
ロードバランスするくり返しなん
情報が流れる際に滞留しないこと
遮断消失するなんてもってのほか
運用するってことは負荷を分散し
故障を自動で切り倒す戦いなんな
こまけーことなんていいんだって
アナウンス出したら負けってこと
上の人に聞いても合ってるはずよ
俺は業務の現場にいたんだからさ

例えばさまあ大丈夫だろうけどさ
仮想化したサーバのコントローラ
壊れたらすごい大障害になるんよ
１００枚くらいのブレードと同じ
まあブレードサーバにしたってさ
コントローラが壊れたら同じだが
だから実際本当に冗長化するなら
同じサービスを二重化しておいて
ロードバランスすることになるが
安いサービスだとされてないかな
でもカゴヤ様とか落ちやしないし
何らかの冗長化はされてるんだろ
ブレードサーバあるいは仮想化の
サーバが数台構成になってるんな
それでだいたいロードバランスが
されてるんだろうと予測しますね

でも僕がいじってたころすでにね
クラウド化仮想化されたサーバが
業務で使われ始めてるころだった
最初ははぁーと思ってたけどねえ
ブレードサーバいらないんかとね
仮想的なサーバってことは実際に
このブレードサーバの一枚一枚を
いらなくするってことになるんよ
仮想化されてるといっても実際は
内部でやってるだけで仮想化した
サーバを僕が落としたら止まるん
あくまでもブレードを仮想化して
多いところに回せるだけですよね
サーバが存在しないわけじゃない

まあその概念は電書会にも常に
活用できてます有難いことです
はっきりいって細部の技術詳細
ってよりも全体の理解も重要で
今僕が語ったことが業務の根幹
かもしれない。故障を出さない
故障が出たら即座に対応するん
新しい技術がもし必要としたら
まさに運用にどう役立つのかを
吟味審議していくことになるし
ヤンさんが仰っていたようにね
海のものとも山のものとも謎の
サーバやサービスは使われない
未曾有の障害の原因になっても
仕方なきことになるからね実際
枯れたサーバ枯れたＯＳですよ

基本的にサーバエンジニアの場合
何はともあれお客様にサービスを
提供するん故障したらアナウンス
出さなければならない法に基づき
だからまず逆算していくわけよね
アナウンスを出さなくていい運用
そのためには負荷や故障率の算定
これくらいの安定性を維持すれば
我々の運用でもカバー可能である
またカバーしやすいような体制を
ハード的にもソフト的にも組んで
それが２４時間３６５日回せるか
花火大会の日にアナウンスになる
年末年始は閲覧できませんじゃね
２４時間３６５日じゃないわけよ

まあそんな風になってるのは
ある程度大規模のサービスで
僕が今イメージしてるよりも
さらに大規模なサービスにも
触ったことがありますけどね
それこそインフラレベルのね
それはもう大変なお仕事なん
保守するためのセンターにも
人が何十人も詰めてるわけよ
億円どころじゃ済まないんよ

サービスの開発はあまり知らぬ
一定のサービスを構築するとか
保守運用するほうが詳しいです
それでも所詮見習いに対しての
明かされてた情報なんて一部の
ものでしかないってことですわ
僕が悪用しても困るだろうから

つまるところさ、

一定のサービスの需要があってね
サーバを何台構成にするってこと
その判断をするためにサービスが
どれくらいの負荷を伴うのかとか
故障する確率がどれくらいかをね
分析してあらかじめ予測するわけ
１台でも故障した際に負荷分散が
発生しても片肺運用で維持できる
障害を復旧させるまでの時間がね
アナウンスを出すまでの３０分に
満たない状態を常時維持できるか

そういう仕事のね

「見習いを！」

やってましたのでね。てへへ。