元々なんでも屋ってたけど、我が部署名もSREになったし、インフラエンジニアって書くと『IT』警察が寄ってくるからSREでいきましょう。短いのはイィ。
SREがやることは書籍『O’Reilly Japan – サイトリライアビリティワークブック』がほぼ語っていますが、もうちょっと噛み砕いて自分的にはこの四大行を軸に活動すれば、いっぱしのSREになれんじゃねっていう戯れであります。
四大行
SREのお仕事を大雑把に表現すると、サービス開発者が作成したアプリケーションを、動かす環境を用意し、安全・効率的に動かし続けることだと思っています。IT業界の事情変化につれて、SREの重要性は高まる傾向にあり、それに伴いSREとして活動を希望する人材も増えたような、そうでもないような。気がするけど、SREとして食ってく気ならこれら四大行が基本であり奥義になるよって話です。
『構築』
アプリケーションを動かすための技術。品質を高くするほど『運用』が楽になり、常人より若さを保つことができる。
『運用』
アプリケーションを安全で効率的に動かし続ける技術。障害を完全に絶つことはできない真理と向き合うことができる。
『負荷試験』
システムでトラフィックを練り流し込む技術。『運用』を活用することで、『構築』やアプリケーションの弱点を見つけることができる。
『費用試算』
システムの価値を大きく決定づける技術。いわゆる必殺技といわれるもので、営業利益に直接的な影響を与えることができる。
構築
かつてインフラエンジニアと呼ばれていた者達がメインとしていた業務領域。古くは物理にまつわる契約や購入・設置から始まり、OSやミドルウェアのインストールに多くの時間を費やしていた──今でも、それらの技術を学ぶ意味はありますが、必要はなくなってきている──というよりは他にやることがいっぱいあります。超大きく分類すると
クラウドを準備し、OSイメージを作成し、アプリケーションが稼働するまで、でようやく基本となります。途中参加の場合、まずこの基本構成を追って理解することが、その後の業務にとって最も効果的で、精神衛生上もよいでしょう。
内容はめちゃ端折ってるけど、実際には使用するコンピューターリソースの種類を決めるとか、デプロイ方法が定まってなければ開発者と相談しつつ決めるとか、細かい設定の適正値を検証する、とかやることは盛りだくさんです。
盛りだくさんですが、目的はわりとハッキリしていて、『安全・安定・効率的に』です。常にそれらを向上できる箇所はないか意識すること、変化させることを恐れない・恐れる状況にしないこと、改善の効果を認識すること、といった心構えが大切です。
そして大きな改善は目に見えて嬉しい成果ですが、同じくらい大事にしたいのは、少し速くなった・少し手作業が減った・少し目視確認が減った、といったチリツモの積み重ねです。そこだけみた１回あたりの効果は小さくとも、長期的に何回も行われる処理ならば、その合計時間は十分に大きな成果といえるからです。
そういった改善を積み重ねるために重要なのは、定期的に技術情報を仕入れること、そして『運用』の感想を取り入れることです。地道で地味な部分ですが、大きめのシステム研究に没頭したり、小さいアップデートを即座に適用して喜んでもらったり、色んな角度から楽しむ要素があります。
運用
これぞSREが心血を注ぐ業務領域。といってもその大半は監視システムの整備とデータ管理にあります。サービスを提供するということは、ハードウェアやミドルウェアにトラフィックが流れ込むということであり、それによって様々なパーツが稼働し、どの程度の稼働量かを表すメトリクスが生まれます。モノによってメトリクスは様々ですが、標準的なメトリクスだけでなく、運用して必要だと思えば独自の項目も追加していきます。
メトリクス値の変動には、いくつかの性質があります。変化幅が小さい値、右肩上がりの値、トラフィックに比例する値、などです。多くの項目には上限値があり、それに伴う警告閾値を定めることができます。変化幅が少ないメトリクスでも、平時の変化幅や他項目と比べて大きく変動した場合、そこ関連が原因と推測するのに役立ちます。
サービスを安定して運用するということは、リソースの構造を理解し、様々なメトリクスの存在を認識し、その正常／異常値を理解することが第一歩となります。
そのメトリクスをグラフ化したり、値の条件を満たすと検知されアラートとなる仕組みを導入することで、いち早く応急措置をし、その後に恒久的な改善対応をしやすくなります。また、対応内容を記録して共有・整理したり、障害率を一定以下に保つ目標をたてることで、運用の品質を上げていきます。
そしてアラートだけでなく、エラーログや遅い処理の類も収集し、できるだけ数がゼロになるように対応していきます。最近だと自社が管理するリソース以外に、外部APIや外部CDNの調子も影響されたりするので、そういった要因も含めてサービスに影響が出る可能性のある要素を網羅的に監視します。そして、可能な限り再発しないよう、自動修復されるよう、少しずつ肉付けしたり穴を塞いでいきます。
メトリクスを適切に扱え、通信や処理の流れを丁寧に追えれば、多くの原因を特定したり、改善点を見出すことができます。要所を定めたら、エラーや障害の修復、パフォーマンス改善などまでが成果の区切りなので、修正そして結果の確認までが一連の流れになります。
プログラミング言語やフレームワーク、SQLといった技量があれば、お願いベースではなく自発的に修正を投げかけることができるので、より迅速効率的に解決していくことができます。これができるかどうかで、作業価値に大きな差が出るので、そういう意味では開発者としての十分な経験を経ることが望ましく、またその方がコーディングをする機会も増えて、より飽きずに楽しく取り組むことができるでしょう。
負荷試験
おそらくサーバーサイドエンジニアが担当することが多いであろう領域。なぜなら、アプリケーションの内容を最も理解している役割の１つだからです。負荷試験というと、やれサーバーやデータを大量に用意しただの、大量のトラフィックをこうやって発生させただの、そういうイメージが浮かぶかもしれません。実際、そういう部分はあるのですが、クラウド時代に大トラフィックを発生させること自体はそう難しくなく、それよりもSREにおける負荷試験には特別な意味があると考えます。
それは【クライアントを操作する】ことです。
普段は業務の多くを『構築』『運用』で占め、サーバー・リソースのご機嫌や調子をうかがう日々ですが、負荷試験は数少ないクライアント関連の理解を深める良い機会となります。だからといって、グラフィカルなインターフェースをいっぱい触るわけではなく、黒い画面を愛でることに変わりはないのですが……
負荷試験を行うにあたって重要な事が２つあります。
ハードウェアやミドルウェアの性能検証でもそうなのですが（参考：ミドルウェア性能検証の手引き | 外道父の匠）、なんとなく負荷をかけて値を採っても的外れな結果になることがしばしばあります。自分の認識外の箇所でボトルネックが発生したり、という理由が多いのですが、より複雑なアプリケーションというモノに対して性能検証するということは、より多くの条件・項目に気を配らなくてはいけないということです。
そのためには、サービスが取り扱うプロトコルと、アプリケーションの仕組みや構造を理解する必要があります。プロトコルの理解が深くなれば、負荷試験ツールでの表現が柔軟で正確になり、アプリケーションの理解はより本番想定に近い条件や実行計画を立てやすくなります。
SREとしてはサーバー側だけでも十分な役割を果たすこともできますが、サービス全体の健全な運用を考えた時、知らない部分が少ないほうが自信を持って迅速適切な判断を下せるものです。そういう意味で、クライアント側の事情もよく理解しておけば、負荷試験だけでなく日常的な運用においても効果を発揮できるため、一度は負荷試験という業務に携わってみるのは大きなメリットになります。
負荷試験環境の準備や実行については、言わずもがな簡潔で迅速であることが望ましいです。必要期間が数日間と短期間であったり、短時間で条件を変えた再試行や結果の検討・修正を繰り返すので、それを見越して取り扱いやすいシステムに仕上げるという、『構築』とは少し異なるベクトルの仕組みを考える楽しさがあります。
負荷試験の重要度は高めなはずですが、時間や人的リソースが足りなくて、開発者が片手間で試験を手掛けることも少なくないでしょう。早めに負荷試験方法を確立しておくことは、そういった不幸を減らし、長期的にみて各所で活用できるので、かなり価値の高い研究開発と考えます。
結果的にはサービス全体のシステム理解にも繋がり、サービスの安定保証を得られるので、技術的な面で言えば総仕上げ的な側面もあるかもしれません。
費用試算
インフラコストは常に上層部から削減のプレッシャーをかけられる存在です。なぜなら、インフラ支出が減れば、ほぼそのまま営業利益の増加に繋がるからです。一口に費用試算といっても色々あり、既存リソースを『構築』の工夫や『運用』の観測によりコスト削減を図る切り口や、新規リソースを『負荷試験』により最適なコスト投入に導くこともできます。
サービスに必要な品質を満たした上で、コスト・パフォーマンスが上がれば成果となりますが、アプリケーションもトラフィックも変動する生き物なので、それなりにリソースの余裕を持ちつつも〆るところは〆る運用バランスが望ましいでしょう。
コスト調整と言えば、Autoscaling機能の適用やリザーブド／スポットインスタンスの採用、インスタンスタイプの調整あたりがまっさきに思い当たるところです。台数を減らせれば単純に費用が下がりますし、同コストで性能が高いサーバーに変更する選択肢があれば、性能が高くなる分やはり台数を減らすことができます。
インフラ観点だけでなく、アプリケーション視点での工夫もたくさんあります。リファクタリングやキャッシュ適用でCPU処理量が減れば台数を減らせる上により高速なレスポンスになります。スマホアプリなら、初回のCDNからのダウンロード機会を減らすことで転送費用が激減します。
細かいところではクラウドだとストレージの読み書き回数など、リソース消費量やリクエスト回数での課金形態があるので、リファクタリングによってそれらを少なく抑えることができれば、費用削減＋レスポンス速度の向上に繋がることが多いです。
サービスの品質を満たしたまま安くする、ということは、適用前よりレスポンス速度が下がることはないし、障害率も下がらないけど、コストだけ下げるということです。これだけ見たらそんな都合のいい話があるわけねーって思える文ですが、システム全体の仕組みや状況を把握していけば、このクラウド時代ならではで、けっこう調整や工夫によって実現できるものです。
現状を把握する力と、手段を思いつく力のどちらも必要であり、軽い表現にするならばエンジニアによる数字遊びみたいなものとも言えます。
しかしその効果は絶大で、部分的にでも費用を半減できたら、その部分のシステム価値は倍になるわけです。この”半分”も大げさな表現でもなく、コスト削減を丁寧に手掛けたことのないサービスがあれば、半減どころか1/10にできる部分があったりします。大きく改善済みのサービスでも、数ヶ月ごとにチェックすれば何かしらあるもので、財布の紐を締めて回るSREとして活躍できれば、その総合力は洗礼を浴びずに済むくらいにはなっているかもしれません。
これらを軸に鍛えていくと、最も重要なことはなにげにコミュニーケーション力だったりすることに気が付きます。
システムの課題や不満を吸い上げたり、逆に問題点を指摘したり適用してもらったり、を円滑に行うには、わかりやすい情報のやり取りや言い方・聞き方が重要になってきます。
別に特別好かれたり嫌われたりする必要はないですが、やるべきことは迅速に取り組んでるんだなとか、お願いや相談をしたらすぐ回答してもらえそうだなとか。SREに限らないかもですが、そういう信用や信頼関係を積んでおくことがお互いにとって、サービスにとって優良な姿勢であると言えるでしょう。
せっかく色んな角度からの業務があるので、広く楽しく効率的に。長く取り組むにはなかなかヤリガイのある職種なんじゃないでしょうかSRE:-)
