SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2018】セッションレポート(AD)

「自分たちなりのSRE」で理想の運用をあきらめない! SIerのエンジニアが挑戦した、顧客のシステム運用変革【デブサミ2018】

【16-B-L】もしSIerのエンジニアがSRE本を読んだら

  • X ポスト
  • このエントリーをはてなブックマークに追加

 オライリー・ジャパンから昨年8月に通称「SRE本」の日本語訳本、『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』が出版され、さらに注目を集めているSRE。サイボウズやミクシィ、メルカリなど大きな自社サービスを展開している企業を中心に、Googleが提唱したITインフラ作りの新手法「SRE」の採用が増えている。では、お客さまのシステム運用を担当するSIerインフラエンジニアがSREを採用することは可能なのか。SREで理想の運用に近づけることができるのか。SIerのインフラエンジニアがSREの考えをうまく取り入れる方法を、エーピーコミュニケーションズのインフラエンジニアである安藤知樹氏が解説した。

  • X ポスト
  • このエントリーをはてなブックマークに追加

SREは大規模サービスにおける運用のベストプラクティス

 エーピーコミュニケーションズは、インフラの構築・運用を中心に手掛けているSIerである。同社インフラエンジニアの安藤氏は冒頭で「システム運用に従事しているエンジニアが『SRE本』を読んでどう感じたのか。またどう仕事に取り入れることができるのか話をしたい」と語り、セッションをスタートさせた。

 まずはシステム運用の理想と現実について、図を見せながら解説する。安藤氏がイメージする、理想の運用の姿とはどんなものか。これまで人が時間をかけて行っていた運用業務を、AIやプログラムが自動で行ってくれる。サービスが見える化され、お客さま自身でメニューから利用したいサービスを選んで利用できるようになる。その結果対応ミスやクレームが減少し、チーム全体が良い雰囲気になり前向きに仕事ができるようになる、といったものだ。「理想は、合理的な文化のあるところで、意味のあるもの、価値の高いものを自分の意思でやる。そうすることで生産性が高くなる」と安藤氏は力強く語る。

 だが、現実はそうはいかない。保守的な文化の中で、決まったこと、お客さまから言われたことをひたすらやり続けるため、やらされている感覚が強く、生産性が低くなっている。「それが現実だが、理想の運用に近づきたい、イケてる運用がやりたいと思っている人は多いはず。そこでイケている運用の代表例としてSRE本を取り上げたい」と語り、SREについて解説を始めた。

運用の理想と現実
運用の理想と現実

 SREはサイトリライアビリティエンジニアリングの略で、日本語訳本のサブタイトルにある、Googleのサイト・サービスの信頼性を支えるエンジニアリングチームのことを指している。同チームにはソフトウェアエンジニアリングやサーバー・ネットワークなどのインフラの専門知識を持つ人たちが集まっており、そのスキルを活用することでGoogleのさまざまなサイトやサービスの品質や運用の効率を高める役割を持っている。「SREはDevOpsの一種や発展系と言われ、読み手によってさまざまな解釈があるが、同書を読んで非常に大きな衝撃を受けた」と安藤氏は語り、SREを「大規模サービスにおける運用のベストプラクティスとして解釈した」という。

 運用のベストプラクティスの第1はリスクを受容することであり、信頼性100%を目指さないことである。まずはサービスの信頼性、すなわちレイテンシーやスループット、可用性などの数値的に評価できる指標、サービスレベルインディケーター(SLI)を基に、サービスレベルの目標(SLO)を定める。

 「SLOによく似た言葉としてSLAがある。SLAはサービスの提供者が利用者にビジネス的に約束し契約する信頼性。したがって、違反するとペナルティが発生する。一方、SLOは身内が目指す目標で、システムを改善していく動機にもなる」と安藤氏は説明する。そして100%から、SLOの値を引いたものがエラーバジェット(エラーの予算)というわけだ。

 「運用チームは100%を目指しがちだが、エラーバジェットの値までなら、新機能の追加、テストなどによって引き起こされる障害のリスクなども受け入れる目安を作ることができる。そしてエラーバジェットを開発と運用が共有することで、対立しがちな関係から、良いサービスを動かすための協力関係へ導きやすくなる」と安藤氏。

 次に「トイル」という考え方を身につけること。トイルとは、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例する、といった傾向を持つ作業のことだ。「SREではトイルを撲滅するため自動化を推奨している。また運用業務は業務全体の50%以下に抑え、50%以上を生産性の高い活動に充てる『50%ルール』を設けていることも、運用のベストプラクティスである」と安藤氏は語る。だが、実際にSREを採用している企業はサイボウズ、ミクシィ、メルカリなど。Googleを含めて大きな自社サービスを展開し、高い技術を生かしている企業がほとんどで、「今の運用現場と大きな温度差がある」と安藤氏は説明する。

 例えばリスクの受容についても、あくまで目標は100%といった意識が強く、エラーを許容する文化はなじみづらい。お客さまありきの仕事なので、SLA的な考え方に傾きがちだ。また万一ミスが起こったときに「100回に1回だからいいんじゃないか、といった考え方にはなりづらい」と安藤氏。そのため「二度とミスはしません」となり、「指標となるデータが見つからない」という。

 次にトイルの撲滅だが、自動化を実現するための技術力が不足していたり、どれが自動化可能な作業なのかわからなかったりする。さらに自社サービス企業ではなく、顧客のシステムを預かって運用しているので、携わる部署や企業が多く、関係者が多いと一度できた仕組みを変えるのが難しいといった現状もある。

 「憧れる気持ちはあるが、まぶしすぎて直視できず、見なかったことにする人も多いのではないだろうか。しかし、あきらめるのはまだ早い」と語り、なんとか取り入れる方法を考えてみたという。

自分なりのSREを実践しよう

 それが「自分たちなりのSREの実践してみる」方法だ。まず安藤氏たちが注目したのは50%ルールである。「価値の高いことをする時間を確保するための戦略と捉えた」と安藤氏。現状の運用現場は運用業務が100%、または100%以上のところが多い。そのため運用以外に割ける時間がなく、運用改善もできない。「そこでトイルの撲滅もその時間を確保するためと捉えることにした」というのである。

 Googleは自動化でトイルの撲滅を図っているが、安藤氏は自動化以外の方法を考えてみたという。第1の方法は取捨選択。「今やっているそのタスクが本当に必要かどうかを検討すること」と安藤氏。「目的もわからず、やることが当たり前になっているタスクの疑問を持つことが大事である」。中には必要のないタスクもきっとある。そういったタスクは勇気を持って捨てることだ。

 第2はアウトソーシング。「そのタスクをやることは、私たちにとってベストなのかを考えることだ」と安藤氏は続ける。他社に代行してもらったらいくらになるんだろうと調べてみると、自力でやるより速かったり安かったり、さらに正確だったりすることもある。「自分の仕事の中で生産性が高いもの、そうではないものがわかる。時間を確保するためにお金の力で解決するのも一つの選択肢だと思う」と安藤氏は強調する。

 第3は順序の入れ替え。運用業務はフロー図やフローチャートに従って行われる。フローの順序は実運用が始まる運用設計の段階で作られる。想定した時間を基に作られるのだが、「実際の運用が始まると想定と違うことがよくある」という。タスクの順序を入れ替えることでフローがスムーズに流れたり、まとまった待ち時間に並列でタスクを進められたりする。作業時間やオーバーヘッドを減らせる可能性があるというわけだ。

 第4は特殊性の排除。運用の中でイレギュラーな対応、例外的な処理は多い。「そういったものがあると非効率で、ミスの温床にもなりうる」。これらを極力汎用的な手順で処理するように工夫するのである。「お客さまと共に検討し、業務の変更を交渉することも視野に入れておくこと」。自動化やコード化をする上でも、共通のモジュールで処理する方が可動性やメンテナンス性も良くなるという。

 第5は自動化。第1~第4で残った業務もしくは整理した業務の自動化を検討するのである。「ふるいをかけている分、自動化する価値も高いと思う」と安藤氏。このように整理しないと、自動化自体が非効率に進められてしまうこともあるからだ。

トイルへの対処法
トイルへの対処法

 以上のとおり、トイルの対処方法にはいくつかの手法があることがわかった。これで「トイルの撲滅をしよう」と俄然やる気になるが、手段や方法論だけでは前に進まない。運用の手順を変えるにはクリアしなければならない大きな壁があるという。「品質を担保できるのか」「周囲の理解が得られない」「関係各所との調製が必要」「変えるための工数の捻出はどうする」「学習コストや教育コストがかかる」などが、直面した壁の例だ。だが安藤氏は「変えるリスクは確かにあるが、変わらないリスクも存在する。変わらなくても安泰とは言えない」と変わらないリスクについての説明を続けた。

 変わらないリスクにはどんなものがあるのか。まずはサービスが成長すると、トイルが増えることによりコストが増え続ける可能性があること。価格競争に負けたり、新技術開発・採用したサービスにシェアを奪われたりといった可能性もある。新しい技術を勉強しても仕方がないといった雰囲気がチームにまん延し、メンバーの成長を妨げたり、やる気をそいだりしてしまう。

 「このように変わらないこと、変わることどちらもメリット、デメリットが両面ある。どちらか一方を過大評価せずに検討することが大事」と安藤氏。進め方も大事だという。いきなり議論を始めてしまうと、拒否反応を見せる人もいるからだ。例えば自動化するのであれば、まずは検証環境で動くところを見せてメリットをアピールしたり、影響範囲やスキルからスモールスタートして、知見と実績をためながら進めたり、乗ってくれそうな人を味方に付けながら進めていくのだ。

 「こういった活動である程度時間が確保できるようになる。得られた時間で私たちはさらなる改善・自動化をしていくつもりだ」と安藤氏。一度で理想に近づけるのは難しい。変化は一度きりではなく継続していくこと。そのためにはスキルアップや技術のトレンドを追いかけることを続けていかねばならない。

 「SRE本は当たり前になっている業務にさまざまな気づきを与えてくれる。本の中に書かれていることもあるが、それを読んで自分の現状や経験と照らし合わせると、さまざまな感想アイデアが浮かんでくる。GoogleのSREチームをまねするのではなく、自己流にアレンジしていくことが大事。得られた気づきを基に、快適な運用ライフを過ごしましょう」

 そう最後に呼びかけ、安藤氏はセッションを終えた。

お問い合わせ

 株式会社エーピーコミュニケーションズ

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/10717 2018/03/23 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング