4年弱勤めたSIerを退職するのでルックバック

about

2021/12に新卒入社し4年弱勤務したSIerを退職しました。1 プライム案件だけやるいわゆる大手SIerです。
本稿は自分が思い/やってきたことの振り返り兼書置きです。ネガティブな話はないので面白味はなくごめんなさい。

whoami

  • 大学に文系(英語と小論文という超私立文系)で入学し、情報系の研究室を学卒という変種
  • 入社してからはサーバ系のインフラエンジニアとして従事
  • スキル/やってたこと:仮想化やSDx/大規模基盤の運用保守

なぜSIerに入社したのか・どんな仕事をしたのか

公益性の高いITの仕事がしたかった

大学時代にちょっとしたきっかけでド文系から情報系専攻に転向したので、ITを使って顧客・社会に貢献したいと思い就活をしていた。
社会インフラを支える仕事がかっこいいなと思い、大規模SIができそうなSIerインターンに参加。その後内定を頂き就職した。結果的に楽しい社会人スタートができたのでよかったが、内定後はちゃんと就活をしなかったことによる内定ブルーに。
そしてそのまま4月を迎えたので斜に構えた痛い奴になってしまい、新人研修中には同期の輪に入れず。そそくさと定時退社してムービル2 でひたすら映画を見ていた思い出がある。

自社クラウドの運用保守

配属されたのは自社クラウドの運用保守を担当する部署だった。尖っていた(浮いていた)自分だったが、部署の方々には受け入れていただき伸び伸びと仕事がでた。

ここで仕込まれたインフラエンジニアとしての基本動作が今の自分の根雪になっている。いわゆるSIerっぽくエクセルと戦う仕事もあったが、手が動かせることが求められる現場でサブコントラクターさん並みに手も動かしていた。特に障害対応は、瞬発力と判断力が求められここでセンスが鍛えられたように思う。落としちゃいけいないシステムとは何たるかということを学び実践することができた。

ITIL的な運用とSIerにいながらサービス運営に携われ大きな経験になった。また、R&Dの起案して静かに炎上させたり、大規模障害を総力戦体制で乗り切ったりとSE/インフラエンジニアとして貴重な経験も積ませていただいた。最後はサブリーダーという形で、数十人のチームをマネジメントも担当させていただいた。

転職すると決めたFit&Gap

前職のよかったところ

昨今のSIerはネガティブなイメージが強いが、私にはよい職場だったのでよかった点をあげたい。

まともな人しかいない

みなどうやったらより良い仕事ができるかを念頭に仕事をされており、Twitterとかで見るトンデモエンジニアみたいな人は私の周囲には存在しなかった。また、数千人も社員がいるとすごいSEが何人もいる。すぐそばにいる良いお手本から技術や仕事の取り組み方を勉強させてもらえたことは素晴らしい経験だった。
また職場の風通しもよく、やりたいことはロジックが通ればやらせていただいたり、理不尽なことで叱責されるようなことはなかった。

待遇面がよかった

まず給料がSIerの中だと抜群によかった。また福利厚生も充実しており、退職金制度があるなどさすが大企業だった。持株が伸びることで会社の成長と実感しながら、自分の資産も成長するところもよかった。

成長の機会がたくさんあった

これが一番良いポイントだった。研修体系がちゃんとしていることはもちろん、手を上げて気合を見せたらやりたいことをやらせてもらえる風土や体力があった。外部の研修等もホイホイ参加していたが、転職活動の中で他社ではそういう訳にはいかないことを知り驚いた。
そして日々の仕事の中でも高い品質が求められる中で、SEとしてブラッシュアップされていった。ここはミッションクリティカルシステムをやっているSIer特有の楽しさと重圧かなと思う。

転職を考えた理由

会社への不満はなく、自分の中にあった以下の2つの気持ちが大きくなったため転職を考えた。

自分を客観視する新しい視点を手に入れたい

今後の自分のキャリアを考えたときに他社でも働いた経験があった方がより面白いことができるのでは、と感じていた。また、前職では一種のコンフォートゾーンに入っており、環境をがらりと変えた方が自身の成長を加速できるのではとも考えていた。

クライアントフェイシングな仕事がしたかった

私はもともとSIがやりたくてSIerに入社したが、入社以来サービサーとして仕事をしていた。一方で根本の「顧客と並走し価値提供をしたい思い」という気持ちは揺るがず抱えていた。ある程度前職の仕事を一通り経験できたこともあり、この思いの実現のために動くことにした。

今後なにやるの

転職先はクラウドベンダーで、ソリューションアーキテクトを担当する。自分のバックグラウンドであるインフラの知識を生かしながら、顧客を支援するという新しい立場で仕事をすることになる。初めての外資かつ初めての職種かつコロナでチャレンジングではあるが、顧客・社会に貢献できるアウトプットが出せるよう精進していきたい。

最後に

前職では、上司・同僚・協力会社のみなさまに恵まれ充実した社会人生活を送ることができました。ありがとうございました。
また転職活動中には選考の中で様々な方と会話する機会をいただけ、その中でもたくさん成長の示唆をいただけ感謝しております。
本稿は自分向けの書置きですが、どなたかの役に立つことがあれば幸いです。


  1. 正確には有給消化をしているので2021/1退職

  2. 横浜にあるレトロなシネコン。当時は1200円とかで映画みれた

IaC本10章

IaC本の読書メモ

序章

  • IaCを成り立たせているのは、ソフトウェアの実行基盤(システム、デバイス)もソフトウェアとして扱うこと
  • そうするとソフトウェア開発のプラクティスを注入できる
  • この章のプラクティスのテーマは、システムに品質を組み込むこと
    • CI/CDの原則を利用して説明する

10.1 システムの品質

  • 優れたプラクティスからは、品質の高いコード・システムが生み出される
  • 品質には機能的要件も大切だが、変化を許すかも重要

10.1.1 品質の低いシステムは変更が難しい

  • 単純な変更を加えたくとも、理解しにくいコードであるとコストがかかる
  • インフラも多くの人の手が加わることで複雑怪奇に

10.1.2 高品質システムは従来よりも簡単かつ安全に変更できる

  • コードを見て変更側かかるようなもの。変更を確認するツール、テストも必要

10.1.3 インフラの品質の着目点

  • Iacを実施しても、定義ファイルに手動変更が入ったりツールの使用が誤っていると脆弱なインフラになる
  • 品質の着目点を、ツールと定義ファイルにシフトすること

10.1.4 高速フィードバック

  • 高品質システムの要は、変更に高速にフィードバックできること。構成変更の旧戻しがすぐにできるか
    • オンプレでこれはどう実現しよう。。。
  • 破壊的な変更を実施したときに問題点を早く見つけられることも重要(CI/CDの意義)
    • テストで事前回避できたらベスト

10.2 インフラストラクチャー管理のためのVCS

10.2.1 VCSで管理すべきもの

基本なんでもVCSで管理すること

  • 管理すべきもの
  • 管理しないもの
    • コンパイル後のソフト
    • ログ、アプリのデータ
    • 機密情報
      • パブクラのセキュリティキーとかですね…

10.3 継続的インテグレーション

  • システムへの変更を頻繁に統合、テストするプラクティス
  • CIツールを使うプラクティスではなく、すべての変更を頻繁にテストするプラクティス
  • テストをしていればすぐに問題点がわかる

10.4 継続的なブランチのテストは継続的インテグレーションではない

  • 多くの変更をしてからマージをする形だとテストが頻繁に行われない
  • 継続的インテグレーションでは全員が自分の変更後トランクにコミットし、完全に統合された行動ベースに対してテストを実行する
    • これだとコンフリクト起こしまくるのでは?(概念を理解できていないだけかも)

10.4.1 ビルドエラーの原因の究明

  • ビルド、テストによるエラーは直ちに対応する必要がある(ライン停止状態)
  • エラーを起こした人は修正するか、変更をリバートする必要がある
  • 放置した状態に慣れてしまうとビルドテストから何も得られなくなる
  • 次節(10.4.2)でも赤いテストを無視するな、冪等でないテストは改修せよという話

10.4.3 インフラストラクチャのためのCI

  • ブランチを作らず、個々のコミットテストが走るようにすること
    • 統合的なデリバリーのため

10.5 継続的デリバリー(CD)

  • CDを支える考えた方は、デプロイできるインフラの構成要素を継続的にチェックする
  • CDはインテグレーションの段階の問題を解決するために使う

10.5.1 インテグレーションの段階の問題点

  • コンポーネントのIFが適切に定義されているから、デプロイがばっちりというのは虚構
  • 大切なのは、本番と同様な環境で継続的にデプロイし続けること
    • これは体感としてみんな持っていそう

10.5.2 デプロイメントパイブラインと変更パイプライン

  • アプリのデプロイと同様に、インフラのデプロイも開発環境でデプロイ・テストしないと本番INさせない
    • 本ではインフラのパイプラインを変更パイプラインと呼ぶ
  • パイプラインが徐々に複雑さを上げながらテストする
    • これは単体、ユニット、結合テストと概念は一緒ですね
  • 本番と全ての工程を揃えることで、問題に早く気がつけるようになる
  • CDプロセスにも手作業の承認を組み込むことができる
  • ポイントは人間の関与を変更の評価やトリガだけに制約すること
    • これはシステムの要件によって変わってくるように感じました。どう自動化に落とし込むか。

10.5.3 継続的デリバリーは継続的デプロイではないということ

  • CDへの誤解にテスト PASS = 本番への適用というものがある
  • コミットで本番に適用されるものあるが、多くは本番Readyな状態になったことを示す
  • 本番に送り込むかの判断は人間がやってもいいが、プロセスはツールが行う
    • この状態を作ることで、技術的にはOKだがビジネスとしてリリースするか判断する猶予ができる

10.6 コードの品質

時間と共に成長するコードベースを、どのようにメンテナンスするか

10.6.1 クリーンコード

  • 良いシステムを産むために必要なものは単純さ
    • 将来の変更をやシナリオを今からスコープに入れる必要はない。変更しやすことが大切
  • 必要とされる物だけを作る

10.6.2 プラクティス:技術的負債をマネジメントせよ

  • 技術的負債は、システムの変更コストやユーザ体験に悪影響を及ぼす
  • 問題点や欠陥は見つけ次第、修正する習慣を身につける

10.7 大きなインフラストラクチャ変更の管理

  • 変更は小さく実施することが鉄則だが、ADのインフラをリプレースするような時には難しくなる
  • アジャイルのやり方を適用するには、分割して小さな変更に落とし込むこと

10.7.1 機能トグル

IaC本輪読 1章「課題と原則」

会社でやっているIaC本の輪読メモ

1.1 なぜIaCなのか

  • IT運用の仕事の課題
    • 最新最良のツール・プラットフォームを導入しても日々のワークロードについていけない
    • システムの抱える問題を修正する時間がない
    • 自動化しようものなら、ポートフォリオが膨らみ破綻させないことだけに時間が費やされる
  • 課題への立ち向かい方
    • クラウドとオートメーションはツールは、インフラの変更の障壁を下げるが一貫性・信頼性を担保しない
    • ツールの使い方・プロセス・慣習は人々が考える必要がある
    • オートメーションが一般になる前のプロセス、構造、ガバナンスは適用できない(ITILv3的な?)
  • クラウド・オートメーションの発展についていくためにInfrastrcture as Codeが必要

IaCとは何か

IaCはソフトウェア開発のプラクティスを、インフラのオートメーションに活かすアプローチ

  • 現代のツールセットならインフラをソフトウェアとデータのように扱えることが前提
  • プロビジョニング・構成・設定・変更を冪等なルーチンにする
  • 変更は定義になり、検証を含む無人プロセスでロールアウトされる

IaCの目標

  • ITインフラが変化の障害や制約になるのではなく、変化を支えて実現すること
  • システム変更がストレスなく日常作業になること
  • Toilからの解放
  • ユーザが自らリソースを作成・管理できること
  • 失敗を完全に防ぐのではなく、簡単スピーディーにHAできること
    • クラウドプロバイダーとしてこれ難しいですよね、責任共有モデルとは...
  • ビックバンではなく、継続的な改善・改良を実現すること
  • 実装・テスト・計測でソリューションの効果が証明できるようになること

クラウドだけじゃないIaC クラウド、オンプレ仮想化だけでなく物理機器にも適用できる 従来手作業でプロビジョニングされてきたサーバは、サーバ構成ツールを使って、構成・設定・アップデートできる

ダイナミックインフラストラクチャが生み出した課題

サーバスプロール

サーバの数が増えすぎると、問題が発生してもすべてのシステムにフィクスを充てるのが難しくなる。サーバのバージョン・構成の違いのせいで、ソフトウェア・スクリプトの冪等が崩れる。 このサーバ間の不統一を構成ドリフトと呼ぶ。

構成ドリフト

  • 誰かがESXiのドライバを変更すると、そのESXIは他のESXiと別物になる
  • JIRAの新しいバージョンが、新しいJavaを必要とするが、Javaの横並びテストができずアップデートしていいか判断できない

違いがあるのは悪くないが、違いが管理できなくなった瞬間に悪

スノーフレークサーバ

スノーフレークサーバは、ネットワーク上の他のすべてのサーバと異なるサーバ

  • Perl5.6を使っていたが、ツールの関係でPerl5.8に移行した。が、重要なアプリが5.8で動作しなかった
  • そのアプリは共有ステージングを5.8にしたときには動作していたが、本番環境を5.8にしたらクラッシュした
    • ステージングには5.8でも動作する特別なサーバが存在した
  • 結果、ステージングには5.6を残し、本番でプリのたびに祈っていた

上記の反省をもとに、IaCの足掛かりを見つけた

  • Infrastrcture.orgでIaCの前触れのような考えを知り
  • 構成ツールで構成・設定し、バージョン管理システムで管理することで反復可能にした

このようなサーバを多くの運用が抱えていることが問題

  • AIXやのような特定の特別なプラットフォームでしか動作しないものもある
  • ただ、それがどのようなサーバであっても、自信をもって素早くし再構築できなければいけない
  • 要件をみたさないサーバがあるなtら、代わりとなるサーバの構築や、再現可能なプロセスを作り上げる必要がある

オートメーション恐怖症

  • オートメーションに自身が持てないのは、サーバに統一性がないから
  • オートメーションの結果が怖いから、ツールに任せっぱなしにできない
  • これは悪の循環なので、自分の恐怖に向き合い、無人実行する
  • 優れたモニタリングと、自動テストの体制が確立すれば自身も生まれる

システム疲労

インフラが時間の経過の共に壊れていくこと(Heroku発祥)

  • パッチあて
  • ログファイルの成長によるディスク減

IaCの原則

簡単に再現できるシステム

インフラのあらゆる構成要素は、人手をかけずに確実に再構成できなければならない

  • 人手をかけずとは、再構築の方法について判断をしなくてよいこと
  • インフラに再現性が生まれると、変更を気軽に実行できるようになる

使い捨てにできるシステム

ダイナミックインフラのメリットは、リソースを簡単にCRUDできること

  • インフラはいつも変化する前提でシステムを設計すること
  • 変化に耐えうるようになれば、実行中のインフラに改良・修正を加えることも簡単になつ

鉄の時代(オンプレ)からクラウド時代での根本的な違い

  • ハードウェアの信頼性が違う
  • 信頼性の低いハードウェアの下で、確実に実行できるソフトウェアにシフトする

統一的なシステム

  • インフラの中に同じようなサービスを提供する2つのサーバがある場合、それらのサーバはほぼ同じでないよイケナイ
  • 不統一な部分があると、オートメーションが信頼できなくなる
  • ただ、構成要素を変更する必要がある場合は(片方のサーバだけ大きなパーティションが必要)
    • 両方のサーバが大きなパーティションを持つように変更する
    • xl-file-serverのような新しいクラスを設定する

反復できるプロセス

再現可能原則に基づき、インフラに対するアクションは反復可能でなければならない

  • ハードディスクのパーティション分割のように、1度限りに見えるタスクは自分でやる方が簡単に見える
  • ただ、チームの同僚が自分と同じようにNTFSでフォーマットするとは限らない
  • スクリプト実行できるタスクは、必ずスクリプトにしなければならない

絶えず変化するデザイン

  • 鉄の時代のITでは、変更を実施するのは難しく、将来のニーズや状況を考慮に入れた設計を行う必要があった
    • システムの使われ方を正確に予想できないため、過度に複雑なシステムが生まれる
    • その結果、変更はより難しくなる
  • クラウド時代のダイナミックインフラでは変更に悩まされない
    • 変更管理しやすく設計されていれば
  • 変更に対応できるようになるもっとも重要な手段は、頻繁な変更
    • 変更が頻繁であてば、変更管理に適した習慣を身に着ける

ラクティス

定義ファイルの利用

定義ファイルの利用はIaCの基礎中の基礎のプラクティス

  • 定義ファイルは、インフラ要素と構成・設定方法をしている巣
  • 定義ファイルはプロビジョニングツールのインプットになる
  • 定義・設定はDBに格納するよりも、テキストで保持する方がアクセスしやすい

自己記述システムとプロセス

  • ドキュメントは変更管理からもれ、虚像になっていることが多い
  • IaCでは、プロセスを実施sるための手順は、プロセスを実装するスクリプト・定義ファイルに書き込まれている

あらゆるものをバージョン管理する

VCSはコードとして管理されるインフラの中心的な構成要素。望ましい状態のインフラはVCSがもとになる

  • トレーサビリティ
    • くわえられた変更と変更者の履歴管理
  • ロールバック
  • 相関関係の管理
    • スクリプト・構成がバージョン管理され、相関関係がタグで示されていると、複雑な問題の解決に役立つ
  • 可視性
    • VCSに変更がコミットされることで、チームが状況を把握しやすくなる。重大な見落としも気づきやすくなる。
  • アクショナビリティ
    • コミットをトリガに、してCI/CDしていく

継続的テストシステム、プロセス

インフラがソフトウェア開発から借用できるもっともの重要なプラクティスは自動テスト

  • 既存の古いシステムのために自動テストをするのは難しい
    • コンポーネントを独立さえないといけない
    • TDDを目指すと、疎結合でクリーン、単純な設計が促される傾向にある
  • 開発中に継続してテストを事項すると、変更に対するフィードバックを素早く返せる
    • フィードバックが早ければ、ひんぱんな変更への自信が生まれる
    • オートメーションへの恐怖心が解消される

一斉変更ではなく小刻みな変更

大きな変更より、小さな変更が望ましい理由

  • 小さな変更をテストして動かす方が、作業量が少ない
  • おかしくなった時も原因がみつけやすい
  • ロールバックも簡単

継続的にサービスを利用可能な状態に保つ

インフラで何が起きても、サービスが傾向できるようにする。サービスとデータをいつでも利用可能な状態にする

アンチフラジャイル:「堅牢」をこえて

堅牢なインフラは典型的な目標だが、IaCでは堅牢を超えてアンチフラジャイルを目指す

  • エクササイズは筋肉を痛みつけるが、体はそれでつよくなる
  • もやしっ子は弱い
  • システムも絶えず変更にさらす方が、堅牢になっていく
    • 対応する組織としても

アンチフラジャイルなITシステムの秘密の成分

  • システム運用者は、システムを理解し継続的に変更を加えなければならない
    • システムを変更できる人もまた、システムの一部
  • ITシステムを継続的に改良するカギは構築・運用する人
  • ニーズの変化に対応できるシステム設計の秘訣は、人を中心に据えて設計すること

まとめ

インフラチームの有能さは、変化する要件をどう処理するかでわかる

  • 労力をかけず、インフラの構成要素を再構築できること
  • パッチが横並びであたり、一貫性が保たれていること
  • メンテナンスウインドウが必要になることがないこと(変更が営業時間中にできること)
  • MTTRを記録し、その改善に力を入れていること
  • チームメンバが、自分の仕事は計測可能な価値を会社に与えていると感じること
    • めちゃ難問...エンハンスはえてして(会社から)評価されない...

Google Cloud Associate Cloud Engineer体験記

about

会社でパブリッククラウドの資格取得がマストになったのでGCPのAssociate Cloud Engineerを取得した話です。

スペック

  • インフラエンジニア新卒3年目
    • 自社クラウド(オンプレ)をやっているので、パブリックの実務経験なし
  • 専門領域
    • サーバ仮想化・ストレージ・運用自動化
  • 保有資格
    • 応用情報、情報処理安全確保支援士、RHCSA

使った教材

Google Cloud Platform エンタープライズ設計ガイド

新品価格
¥2,822から
(2020/9/12 16:59時点)

  • GCP提供の模擬試験
    • 公式が公開している模試なので、全問スラスラ正解できるようになるまで1hくらいがっつり復習
  • 【GCP認定資格】Google Cloud Platform Associate Cloud Engineer模擬問題集
    • udemyでかった模擬試験。120問あるかつ、全問解説付きでよかった

勉強法

  • 試験1週間前まで
    • あまりやるきがでなかったので、だらだらとCourseraを見て過ごす。
      全部見るのに足掛け3ヶ月くらいかかったが、本当は3週間もみっちりやったら終わる分量。
    • 本もちょくちょく斜め読み
  • 試験1週間前から
    • GCP公式の模擬試験をといた。正答率は17/20でそこそこ。
      ドキュメントがついているので、CourseraであまりトピックのないKubernetes系のコマンドをおさらい
  • 試験前日
    • 上記の模試を一夜漬け勉強。問題を解くことで、試験問題に慣れを作った。
      正答率は5割くらいだったので、8割になるまで2周した。(公式の模試も復習)
  • 試験当日
    • コロナの影響か、試験センターがガラガラ。身分証明書類を2種類用意を忘れないように。
      私は印刷したが、受験票は印刷して持っていかなくてもOKそうな雰囲気だった。
    • 試験自体は30分ほどで解き終えれて、見直し15分とかですぐ終了
    • 正当か自信があった問題は7割くらいだったのでおそるおそる試験終了した

問題の印象

  • gcloud系のコマンドはざっとおさらいが必要
    • コンソール は試験前までに絶対触っておいた方が良いです!!!
  • ユースケースを問われる問題もあるので、サービスの制約や機能から逆算する必要
  • コンテナ系の出題も多く、時代はVMではない...という印象

受験して良かったこと

  • 業務でパブリッククラウドをさわれない中、体系的な知識を手っ取り早く身に付けられた
  • Courseraの動画ではSREの話とかもポロポロ出てきて面白かった
  • プライベート・パブリッククラウド、どっちもチョットワカル状態になれたこと
  • ここ数年なくなっていた資格取得のモチベが再燃したので次はProfessionalとりたい!

Chap 20 - Load Balancing in the Datacenter

会社でやったSRE本の輪読。後半のアルゴリズムは口頭で説明したからあっさり。

Load Balancing in the Datacenter

・データセンター内での負荷分散について
┗クエリのストリームを負荷分散するアルゴリズムについて

データセンターに到達するクエリのストリームを想定すると

  • クエリをさばくプロセスがデータセンター内にある
    • サービスは置換可能なサーバプロセスとして動作する
    • サービスは3つ以上のプロセスから、大きいものでは1000以上のプロセスで構成
    • これらのプロセスをバックエンドタスクと呼ぶ
  • これ以外のタスクをフロントエンドタスクと呼ぶ
    • フロントエンドタスクは受信クエリごとにバックエンドを接続

ほとんどのHTTPリクエストはGFEに到達し、GFEはここのプロセスにルーティングする
┗単独のHTTPリクエストが、複数のシステムへの依存のある遷移を引き起こすとファンアウトが大きくなる

The Ideal Case

理想的なケースでは、特定のサービスの負荷は、すべてのバックエンドタスクに完全に分散され、 特定の時点で、負荷の最も少ないバックエンドタスクとまったく同じCPUの量が消費される

データセンタにトラヒックを送れるのはタスクがサチるまで。 サチるとデータを制御する必要があるが、CPUとしては効率が悪くなることも

酷い場合には1000CPUを予約していて7割使用していないことも

Identifying Bad Tasks: Flow Control and Lame Ducks

バックエンドタスクを決定する前に、バックエンドプール内の異常タスクを特定して回避する必要がある。

A Simple Approach to Unhealthy Tasks: Flow Control

  • クライアントタスクがvバックエンドタスクへ送信したアクティブなリクエスト数をトラッキングする
  • 特定の接続数に達したらリクエストを送らないようにする
  • リクエストが積み重なるとワークロードは他のバックエンドで実行されるようになる

  • 極端な環境下では有効だが、その前にバックエンドを食いつぶすのが普通

  • またバックエンド的には余裕がるが、セッション数としてサチッたとみなされリソースが有効活用できない場合も
  • リクエストをすぐ返さないような制限がかけられている場合は、この制限が逆墳して全てのバックエンドに到達負荷になる場合も
    ┗アクティブリクエスト数を上げると回避できるが、タスクが異常かどうかの判断はできない

A Robust Approach to Unhealthy Tasks: Lame Duck State

クライアントからはバックエンドは以下の3状態に分類される

  • healthy
    • 正しく初期化され、リクエストをさばく
  • コネクションを拒否
    • バックエンドが応答しない、タスクが落ちているか異常状態
  • レイムダック
    • ポートをリッスンしているが、リクエスト送信の停止を応答する

タスクがレイムダック状態になると、クライアントはその状態をブロードキャストする
googleのrpc実装では、インアクティブでもヘルスチェックUDPを投げるので状態がインアクティブと判断ができる

レイムダック状態でタスクが存在するの利点 - シャットダウンしているバックエンドでアクティブになっていたリソースへのエラー通知を回避できる
┗エラー処理をせずにバックエンドタスクを停止すると、他のタスクへの影響もある。シャットダウンのフローは以下。

  1. ジョブスケジューラがSIGTERMシグナルをバックエンドに送信
  2. バックエンドはレイムダック状態になり、他のプロセスにリクエストするように返答する。
  3. レイムダック前に受け付けたリクエストは正常に処理される
  4. リクエストがクライアントに戻るごとに、レイムダックバックエンドの球持ちはへる
  5. 一定のインターバルのち、バックエンドは正常終了するかジョブスケージューラにkillされる。

Limiting the Connections Pool with Subsetting

ヘルス管理に加えて、負荷分散のもう1つの考慮事項はサブセット化。 クライアントタスクが相互作用する潜在的なバックエンドタスクのプールを制限する。

  • クライアントバックエンド間のアクティブ接続時間を短くする試みが必要
    ┗ヘルスチェックにはTCPじゃなくてUDPを使うような
  • コネクションはCPU, メモリも食うのでサブセット化により負荷をならす

Picking the Right Subset

  • 適切なサブセットサイズはシステムの挙動に左右される。
  • サブセットサイズを毛亭したら、サブセットを定義するアルゴリズムが必要

A Subset Selection Algorithm: Random Subsetting

  • クライアントがバックエンドリストをシャッフルして使えうものを使う
     ┗効率が悪かった

A Subset Selection Algorithm: Deterministic Subsetting

ランダムなサブセット化の制限に対するGoogleのソリューションは、 確定的サブセット化

def Subset(backends, client_id, subset_size):
  subset_count = len(backends) / subset_size

  #クライアントをラウンドにグループ化します。 各ラウンドは同じシャッフルリストを使用します
  round = client_id / subset_count
  random.seed(round)
  random.shuffle(backends)

  #現在のクライアントに対応するサブセットID:
  subset_id = client_id % subset_count

  start = subset_id * subset_size
  return backends[start:start + subset_size]

クライアントタスクを「ラウンド」という単位で分割する
round i = subset_count * i
subeset_count = バックエンドタスクの数を目的のサブセットサイズで割ったもの
[ subset_count = 12/3 ] = 12のバックエンドタスク必要なサブセットサイズが3

クライアントが10個ある場合、前述のアルゴリズムは次のshuffled_backendsを生成する可能性がある

  • ラウンド0:[0、6、3、5、1、7、11、9、2、4、8、10]
  • ラウンド1:[8、11、4、0、5、6、10、3、2、7、9、1]
  • ラウンド2:[8、3、7、2、1、4、9、10、6、5、0、11]

重要な点は、各ラウンドがリスト全体の各バックエンドを1つのクライアントにのみ割り当てること
優れたアプローチとしては、ラウンドごとに異なるシャッフルを使用して、残りのすべてのバックエンドにこの負荷を分散すること

Load Balancing Policies

クライアントタスクがサブセット内のどのバックエンドタスクがクライアント要求を受信するかを選択するために使用するメカニズム
ロードバランシングポリシーの複雑さの多くは、クライアントがそれぞれに使用するバックエンドをリアルタイムで決定すことによる

Simple Round Robin

  • 一定程度は有効だが、クエリの変動やリソースのバースト等によってコストがうまく分散できない

Small subsetting

  • 作業量単位を小さくしてバックエンドごとの作業量をならす
  • 異なるプロセスが同じバックエンドを利用すると、クライアント間でリソース使用量が大きく変わる
    トラヒックを大きく生成するクライアントのサブセットのバックエンドが高負荷に

Varying query costs

  • クエリコストに大きな差異があるシステムでの負荷分散は難しい
  • インタフェースを標準化するため、重いリクエストを標準としてサービス設計をすることはある
    • そうすると一部のバックエンドに重いたタスクを裁く必要が生じ、最悪は応答不能

Machine diversity

  • 同じデータセンター内のすべてのマシンが必ずしも同じであるとは限らない  - マシンごとに処理能力が違うとラウンドロビンじゃ分散できない
  • googleはGCUというCPUレートの仮想ユニットを作り、それを各CPUをパフォーマンスに応じてマッピング

Unpredictable performance factors

パフォーマンスに寄与する多くの予測不可能な要因の2つ - 敵対的な隣人
他のプロセスによる影響。メモリキャッシュ内のスペースや帯域の奪い合い。 - タスクの再開
タスクが再開されると初期に高負荷がかかる

Least-Loaded Round Robin

各クライアントタスクがサブセット内の各バックエンドタスクに対するアクティブリクエストの数を追跡し、最小数のアクティブリクエストを持つタスクのセット間でラウンドロビンを使用すること

Weighted Round Robin

これがいちばんよかった

Chapter 11 - Being On-Call

勤め先でSRE本を輪読している時のメモ。

 

### オンコール対応
オンコール対応は、サービスの信用性と可用性を保つための重要な仕事

11.1 イントロダクション
・オンコールの対応は専門の運用チームにより実施されてきた
googleではSREチームが実施している
 →ソフトエアエンジニアリングを適用したにと大使しきれない量のため
 →ここでも運用作業の時間が50%のキャップ、チームの力をスケールさせるのがSREの仕事

11.2オンコールエンジニアの日常生活
・オンコールエンジニアの業務
 障害対応、プロダクトの変更の実施や調査
 時間制約は5-30分(厳しいいいい)
・アラート配信システムは柔軟
 メール、SMS、自動コール、アプリなど←これはNRIもそう
・レスポンスタイムはサービス可用性に依拠する
 ユーザが直接利用するようなサービスは4ナインで、その場合許されるダウンタイムは13分/四半期
・コールのローテーション
 プライマリとセカンダリのコール
 この2人のエンジニアの使い方はチームによって異なる(取り逃しを拾ったり、小さいインシデントをひき受けたり)

11.3バランスの取れたオンコール
オンコールは質と量ではかられ、固有の制約を持つ。SREマネージャーは2つの軸を持続可能な状態に保つ責任を負う。

11.3.1量におけるバランス
・時間の配分
 50%はエンジニアリング オンコールは25%以下 他の仕事をもう25%とする
・25%オンコールルール
 24/7かつ25%コールを保つには、週替わりで回すと8人のエンジニアが必要
 2サイトでやるなら6人
・マルチサイトがよい
 夜間シフトを避ける、プロダクションシステムとの接点を増やすため、エンジニア数を制限する
 上記の観点からマルチサイトを推奨。しかしコミュニケーションのオーバーヘッドがあるのも事実。
11.3.2質におけるバランス
・オンコールの質的負荷
 1つのインシデントのフォローには平均6時間必要(フォローアップの活動まで含めて)
 とすると1日に対応可能なインシデントは2件になる
11.3.3 保障
時間外の勤務への補償
・チームで異なるが代休または給与で調整

11.4安心感
人は障害対応のときに以下の対応をする
・直感かつ反射的
・理性的かつ、集中力を球持ち、慎重な認識を働かせる
ストレスホルモンが高い環境だと全社の選択を取り勝ち
→同じアラートが4回飛んできたとき、4回目が3回目と同じ対応が適切とは限らない

・理想は...
妥当な判断が下せるだけのデータをそろえ、用意した手順を実行する
並行してその推定を批判的に検証する

・オンコールに必要なリソース
 明確なエスカレーションぱす
 しかっり規定されたインシデント管理の手順
 非難を伴わないポストモーテム

・インシデント管理方法
googleではツールが導入されており、メールや状況更新に煩わされることはない
NRIでは..?

11.5不適切な運負荷の回避
11.5.1.運用の負荷
・運用の負荷を計測できるようにすべき
・優先度の低いアラートのハンドリング
→アラートとインシデントを1:1にできるのが理想
・場合によっては障害通知をアプリに返却する
→適切な頻度になるまで協業する
→SREとDevチームのバランスが保たれているからこれができる
11.5.2低すぎる運用負荷
・プロダクトのとの接点が減るため良くない
→四半期に1回or2回は本番システムにさわれるのが目安
・不運の輪という全社規模での災対訓練を年に1度実施している
cf.カオスエンジニアリング

11.6まとめ
・オンコールにもエンジニアリングの力(SRE)を導入して、コール対応をスケーリングさせよう

Chapter 16 - Tracking Outages

勤め先でSRE本の輪読をしている時のメモ。

# サービス障害の追跡 ・長期にわたる信頼性の向上は基準点を設定して進捗のトラッキングが可能なことが条件 ・Googleではoutlatorというシステムを利用  └アラートを受信 データにラベリング グループ化 分析を提供 ・ポストモーテムは個々の障害について詳細な情報を提供  頻繁かつ広範囲な問題を検討するには全体の確認できる必要  └シフトごとに何件コール? 対処必要だったアラートは? 何のサービスが最もトイルを生む? ## Escalator ・SREへの通知の全ては、人間が通知を受信したか中央のシステムで管理 ・確認応答されない場合は、次の当番にエスカ ## Outlator ・Outlaorは障害チケットを管理するツール ・Outlatorには元の通知のコピーが保存される←情報が一元的に管理される  ├通知には"重要"等の注釈を付与できる  └通知はグループ化も可能 ・Outlatorのようなシステムはチャットと相性が良い ### 集計 ・1つのイベントで複数のアラートが発生することは間々ある  #サーバダウンでサーバとNWと両方ダウン検知  └フォールスポジティブ、フォールスネガティブを考えると通知は減らせない ・対応は複数アラートを1つにグルーピングすること ### タグ付け ・すべてのアラートがインシデントではないので、区別のためにタグ付けをする  └フォールスポジティブやテスト、人による誤送信 ・outlatorでは一単語でタグ付けをする、コロンがセパレータになる  └ex. "cuase:network" "cause:network:switch"など ・またタグはリンクにもなる  └"bugs:76543"のように ### 分析 ・履歴データはインシデント対応に役立つ  └前回に何を実施したかも重要だが、体系的・周期的・広範な問題を解析するときに障害の追跡は重要 ・分析の根底にあるのは、基本的な集計情報(週/月/四半期など) ・次のレイヤはより重要で、チーム/サービスを時間経過で比較しパターン・傾向を分析する  └過去のデータと比較することで、データが正常を示しているのか、異常を示しているのか判断できるようになる ・データ分析の次のステップは、データから意味を解釈すること  └インシデントの原因になっているコンポーネントを特定し、改善出来たら嬉しい ### 予想外のメリット ・アラートが他の障害と同時に発生しているとわかることはメリットがある  ├インシデントの発生を認識することで、調査の迅速化と他チームの不可を下げることができる  └システムに障害が発生しているにアラートが飛んでない時は手動で通知する ・ダミーのエスカレーターを使うことで、通知を人間は受信しないが  Outlatorで管理するようにすることもできる。  ├特権ユーザの使用履歴を管理する  └冪等でない結果のジョブをトラッキングし、結果に注釈付けする