クラウド時代の運用保守に求められるSREの考え方とは
スリーシェイクは2015年創業。社名はインターネットで接続を確立する手順「three-way handshaking」を由来とし、クラウドネイティブな技術に強い。なかでもSREを熟知したエンジニアが多いのが特徴で、SREの戦略策定から構築や運用までを支援するサービス「Sreake」を提供している。スリーシェイクのSRE領域に対する知見の確かさは、その提唱者であるGoogle CloudのオンラインセミナーでSREの解説をしていることからも伺い知ることができる。
あらためてSREの背景にあるIT基盤の運用保守に目を向けてみると、ここには長らく難しい問題が内在している。特に、作業に繰り返しが多いこと、属人化してしまいがちで誰かに作業が偏ってしまうことなど、読者のみなさんも多かれ少なかれ感じたことがあるのではないだろうか。また、システム障害の発生の起因としては、何らかの更新が加わったタイミングが最もリスクが高いということもある。運用保守の現場では、大小さまざまな困難を日々乗り越えつつも、何らかの懸念や危うさのようなものがうまく可視化されないまま常に横たわっている。
手塚卓也氏は運用保守の実状について「2000年代など、古い時代に構築されたシステムはいわば“塩漬け”を前提としていました」と指摘する。一度構築したら問題がない限り、変更を加えることなくそのまま運用を続けるのが当然のような感覚だ。しかしインフラをクラウドに移し、頻繁にアプリケーションを更新することが求められる現在では、そういうわけにもいかなくなってくる。こうした課題感に「SREの考え方が参考になり、生きてきます」と手塚氏は言う。
例えば金融機関の基幹システムもかつては塩漬けが多かった。しかし今ではスマートフォンアプリを介したQRコード決済やポイント払いなど、決済サービスが多様化している。塩漬けした基幹システムだけを保守すればいいなんてことはない。「それでは時代に追いついていけません」と手塚氏。
とはいえアプリケーションやインフラで更新を加えれば、前述の通りリスクも増加する。そのために今はリリースサイクルを早めながらも、サービスの信頼性を維持していくことが求められている。だからこそSREが重要になってくるのだ。
もともとSREはソフトウェアエンジニアが担うものと考えられている。というのも、SREとは運用保守に関するものをソフトウェアエンジニアに依頼する時に生まれる仕事が多いからだ。しかし日本においては、SREは運用保守の領域にあるためかインフラエンジニアが担当するケースが多いのが実状だ。
手塚氏は「ソフトウェアエンジニアでもインフラエンジニアでも、SREはどちらのルート出身でもいいと思います。いずれにしても1人で担えるものではないですから。SREが担う領域は広いため、いろんな挑戦があります。そこはキャリアの視点から見ると魅力的に映るのではないでしょうか」と話す。
また、サービスが維持できていれば、具体的なところは「ふわっと」曖昧に済ませているところもあるかもしれないが、後述のようにSLO（サービスレベル目標）やさまざまな統計値を使いこなせるようになると、経営やビジネスのメンバーと会話しやすくなる。
このようにSREは多くの価値をもたらすことができるものの、その実現には広範にわたる技術が求められることから奥が深く、導入も単純ではない。そこで、スリーシェイクのような専門家集団が求められる。手塚氏は「私たちが持つ数多くの事例やノウハウが一番の価値だと思います。言い換えれば引き出しの多さです。あらゆる環境や状況でも最良の解決策を提案できます」と話す。
SREの導入はそう簡単ではない。最初はプロフェッショナルの知見を参考にしながら進めることが一番の近道ではないだろうか。
