Culture Entry

SRE(Site Reliability Engineer)になる意味

2019-04-24

author:

SRE(Site Reliability Engineer)になる意味

Molly Struve          
Kenna SecurityのリードSREですが、大半はElasticsearchに掛かりっきり。講演者でランナー、障害馬術プレーヤーとしての顔も持つ。常に野心的で、決して満足しない。

SRE(サイトリライアビリティエンジニア)の私が一体どういう事をしているのか、非常によく聞かれるので、投稿することにしました。

SREとは?

SREには様々な定義があるので、まずはKennaでのSREの定義からご説明しましょう。

SREとは、ソフトウェアを使用してパフォーマンスの最適化を図り、すべてのシステムに渡って安定性と信頼性を確保することに焦点を当てる、開発者のグループである。

私たちはチーフエンジニアと話し、SREは「開発者+α」と取り決めました。「+α」は、単にコードを書くこと以上の知識を表しています。私にとってその「+α」は、Elasticsearchがどのように機能するかについての包括的な理解です。他の人々にとってのそれは、Ansibleのようなフレームワークとシームレスに連携する能力かもしれませんし、コンテナに関する深い理解かもしれません。また、SREの仕事を助けるであろう技術関連のほとんどすべてにもなり得ます。

もう一つ、私が良いSREの特徴だと感じているものは、システム全体がどのように機能するかを見て、理解する能力です。システムの小さな部分を理解するのは簡単ですが、すべての部分がどのように組み合わさっているかを概念的に理解することが、SREであるための鍵です。高度な知識を持つことで、システムの最大の弱点を見つけ出し、それらを改善してシステム全体の信頼性を確保することができるのです。

私たちのKennaでのSREの定義から考えると、業界に入ってきた人々はSREのポジションに移行する前に、まずフルスタックまたはバックエンドの開発者としての役割から始めることが重要でしょう。開発者としてのスキルを置いておいて、多種多様なソフトウェアツールに触れることで、もし最終的にSREになりたいと決心すれば、その時ははるかに成功できることでしょう。

私がSREになった経緯

元はと言うと私は、フルスタックの開発者でした。フロントエンドのJavaScriptからバックグラウンドワーカーまで、すべてを手掛けていました。ごく一般的なソフトウェアエンジニアとして2015年にKennaに入社したときも、私の仕事は相変わらずでした。私の入社後間もなく、Elasticsearchクラスタで主に作業していた上級開発者が、退社しました。私はこれが、何か新しいことを学び、また自分たちのインフラの一部を所有できる機会ではないかと考えました。私はElasticsearchについて、可能な限りすべてを学ぶことにしました。Elasticsearchの研修に出かけ、文献もたくさん読みました。徐々に私の日々の仕事が、Elasticsearchに焦点を当てたものになっていきました。

時間が経つにつれ、私はバックエンドとElasticsearchに注目するようになりました。私の重心が変わっても、Kennaは成長を止めませんでした。2017年秋のこと、我が社は肥大化してきたため、中核の開発チームを複数のチームに分割することにしました。この時、私たちは他社からもSREを一人雇っていました。そして私は彼から、Kenna初のSREチーム結成に参加しないかと相談されたのです。私はすでに、中核データストアの一つであるElasticsearchの信頼性とパフォーマンスに注目していたので、この提案はぴったりだと思いました。もちろん、承諾しました!

SREの仕事

SREチームが最初に設立されたとき、仕事は膨大にあり、私たちは多忙を強いられました。Kennaのプラットフォームは狂ったように成長していましたし、私たちはスケーリング問題をいくつか抱えていました。私たちのチームの最初の焦点は、手に入れた新たなデータすべてを処理できるよう、コードを最適化することでした。Datadogのような監視ツールでは、最適化する必要のあるコード内のスローなクエリやホットスポットを探すために、多大な日数を費やしました。最初の1年間に私達がしたことについてより詳しく知りたければ、私の「Cache is King」でのスピーチをご覧ください。このスピーチでは、私たちがコードベースに対して行った、5つの非常に大きな最適化について説明しています。これにより、パフォーマンスが大幅に向上しました。セクシーなグラフがいくつもありますよ😉

パフォーマンス向上以外にも、初年度の間に私たちのチームはこれだけのことを行いました:

  • 監視フレームワークの全体を徹底的に見直し(近いうちにこれについても投稿します!)
  • アプリケーションに拡張されたロギングを追加し、よりアクセスや検索がしやすいようにログストレージを改善
  • サポートエンジニアが加わったために不可欠となっていた、管理サイトの改善
  • アクセス制御の改善。一例として、制作とやり取りする際にエンジニアが使用できる、読み取り専用コンソールの設定。
  • 複数の仮想プライベートクラウド環境を処理するための、継続的インテグレーション(CI)ワークフローをアップデート。

未来予想:KennaのSREロードマップ

KennaのSREチームは、2年目を迎えました。私たちは多くのことを成し遂げてきましたが、Kennaが成長を続けるにあたり、やるべきことはまだたくさんあります。私たちのロードマップには現在、次のようなプロジェクトがあります。

  • Elasticsearchを6.xにアップグレード。 前回のアップグレードは大雑把だったので、今回のアップグレードに関連した広範なテスト計画をいくつか立てています。
  • サービスレベルの目標設定。 私たちの顧客は今幸せですが、それは測定基準の観点からはどうでしょう?顧客を満足させるためには、どれだけ速く検索をロードする必要があるか?データ処理はどのくらいの速さか?私たちの目標は、このような質問に答えを出すことです。
  • すべての新たな仮想プライベートクラウド(VPC)環境を管理。 多くの大手クライアントは、Kennaを実行するための独自の仮想プライベートクラウドを望んでいます。これは、たくさんの異なる環境があることを意味します。ご想像のとおり、それらすべてを同期させて使用することは困難です。今年我が社ではVPC数が増えてきたため、私のチームはすべてのVPCで可能な限りシームレスな作業を実現したいと考えています。
  • 負荷テストフレームワークの実装。 プラットフォームがどれくらいの量を扱うことができるか?と、私たちは絶えず質問を受けます。現在のところ、私たちはこう答えます🤷 制限というものが何であるか、実際に知っておかれるとよろしいでしょう。

SREチームとKennaが成長を続けるにつれて、チームの役割と責任も進化していくものと私は確信しています。一年後にどうなっているか、非常に楽しみです😃

私がなぜSREであり続けるか

なぜなら、この仕事が大好きだからです!嘘偽りなく、本当に大好きです。クライアントに大きなプロジェクトを提供できるフルスタック開発者時代も私は十分楽しんでいましたが、それでもSREの方がはるかに好きです。以前は、私の一日の大半は、一部のクライアントから要求された機能の構築に費やされていました。今、私がしている作業はプラットフォーム全体とすべてのクライアントに影響します。私はバックグラウンドジョブでコードをいじり、一部のみならず全クライアントのデータ処理を高速化することができます。そのような規模の変化や改善に影響を与える能力を持っているというのは、素晴らしいことです。

私はまた、自分が作るものを非常に真剣に考えています。カスタマーサービスのローテーション業務に数年間費やしたおかげで、私は非常に思慮深く、クライアント体験に敏感になりました。顧客のプラットフォームをより安定した信頼性の高いものにするため注力するという私の夢は、実現したのです。 もしあなたがバックエンドの作業を楽しいと感じ、システムのパフォーマンスや信頼性、スケーラビリティにより近づきたいのであれば、SREの役割がぴったりです。

参考

SREになるということについてより詳しく知りたければ、GoogleのSRE本を是非ご覧ください!

脚注:サイトリライアビリティエンジニアの定義については、どこでもわずかな違いがあるでしょう。もしサイトリライアビリティエンジニアの職に応募するのであれば、その仕事における責任が確実にあなたの望むものとなるよう、面接でしっかり質問しておくことです。

この記事は、著者の許可を得て翻訳しています。なお、原文はこちらです。