SREとしての「コスト最適化」

Transcript

1. SREとしての「コスト最適化」 技術統括部 ITインフラソリューション部 小野哲人 2022年06月
2. 1 アジェンダ アジェンダ 1.自己紹介 2.SREの役割 3.SREを始めるにあたって 4.実例紹介 5.まとめ
3. アジェンダ １．自己紹介 〇経歴 ①オープン系インフラの「プリセール」・「システム化構想検討」・「要件定義」・「設計」・「構築」・「保守」 SI自体をフレームワーク化し、効率的に案件を遂行できる。 ②担当セクターが「金融」、「官公庁」が多かったため、より堅牢なインフラを構築してきたと自負している。 ③新規インフラ事業計画の企画、遂行 某大手SIer所属時には現在のクラウドの前身となる新規事業にリーダとして参画し、推進していた。 IaaS～SaaSまでのモデルなどの作成に貢献した。 〇資格取得履歴 SCSA（SunMicroSystems） IBM eServer Certified Systems Expert - pSeries HACMP for AIX5L IBM eServer Certified Specialist - pSeries Administration and Support for AIX 5L v5.2 PMP（PMI） IBM eServer Certified Specialist - eServer p5 Solution Sales IBM Certified Specialist - eServer p5 and pSeries Administration and Support for AIX 5L v5.3 ITIL IBM PureFlex Systems Sales V2 IBM PureFlex Technical Support V2 AWS 認定クラウドプラクティショナー AWS 認定Solutions Architect – Associate 経歴サマリ 魚釣り 魚を「釣って」、「食べる」までを信条としている。 （Catch＆Eat） ・釣る ・食べる（行きつけのお店で調理してもらいます(^^♪） 趣味 ビジネストランスフォーメーション事業本部 品質・技術統轄部 技術サービス推進部 ITインフラソリューション部 小野 哲人 おの てつと
4. 3 SREの役割 2.SREの役割 SRE サイト信頼性エンジニアリング 運用自動化の推進 不要なオンコール の削減 SLO/SLIの定義 ★コスト最適化★ （コストコントロール） PostMortemの実施 Toilの削減 インシデント管理 CI/CD エラーバジェット ↑今回のスコープ Observability
5. 4 SREを始めるにあたって（お試し提案） 3.SREを始めるにあたって（お試し提案） SREの 課題 認知度低い、、、 なにやら、難しそう、、 お試し提案 お試し SRE活動 効果測定 恒久的 SRE活動 そうだ、まずは、トライアル的 に、始めてみよう！ 予算も貰えたので、ここで、 やっと、SRE的な活動がで感 じ、、、 SRE実施して、どんな効果 があったか測定・報告 SREっていいねーー じゃ、うちも、本腰入れる かー！SREに、、、 まだ、SRE自体、日本では認知度 低いし、組織再編や決裁権をもっ た上席の方は特に疎いと感 じる。 よって、SRE活動する予算を頂戴 するの難儀、、、 でも、SRE活動すれば、より良いサ イト（システム）になり、効果はでる はずだと確信はしている。。。 もちろん、やるためには予算が必 要である。。。 では、この予算をまずはどう やってもってこよう か？？？ 以下などの施策の中でも上席に 刺さりそうな施策をまずは実施 ①トイル削減 →自動化開発費用に充てる ②オブザーバビリティ →新規APM導入費用に充てる ③品質の高いリリース →効率的なCI/CD環境の構築費 用に充てる ・・・etc コスト最適化（コストコントロール）により、コスト削減できた場合は、本予算枠 をSRE活動費用として、利用してよいことを上席、または、顧客と握り、 この予算枠の範囲で、トライアルを実施することを合意する。 ユーザ企業側：削減コストををSRE費用に割り当てるだけなので、Win。かつ、SRE活動によりさらなる顧 客利便性向上に寄与 SIer側：自ら、墓穴を掘るような形になってしまう場合もあるが、SRE活動費用を別途いただけるので、 まーま、Win 今後SREに寄与し、パイの拡大や信頼を勝ち取ることができる
6. 顧客概要 4.実例紹介 • お客様：XXXX • システム概要 • 約3年ほどで新規にAWS上にシステム基盤を構築し、2019に主要機能をローンチさせた。 • 課題 ①早急なビジネス要望に追い付くため、迅速なシステム構築をシステム部門は問われ、突貫で、 システム構築が行われたため、システム的な欠陥（IT統制にも不備がある）が顕著化していた。 ②マルチベンダーにて各システムが構成さてていたため、顧客側体制不足もあり ベンダーコントロールがきちんとなされていない現状があった。 ③主要機能ローンチ後、さらなるサブシステムのローンチが予定されており、その案件推進として、 顧客側のインフラ要員不足があった。 • SHIFTへの期待 • 顧客側インフラの代替要員（インフラPMO）として、上記課題を払拭することを期待されていた。
7. 6 課題・提案と実施内容 4.実例紹介 No 課題/提案 対応（一部例を抜粋） 課題１ システム的な欠陥（IT統制にも不備がある） があった ①スパイクに対応できていない→まずは、「流量制御」の提案 以下★日経BPの記事★参照 https://active.nikkeibp.co.jp/atcl/act/19/00318/121000004/index.html ②ログ標準化（現状はログの保存期間などが無制限になっているため、PCIDSSに準拠した形で、整理した） 課題２ ベンダーコントロールができていない ①会議体の席などでは基本的に顧客側がなめられている印象があった。→ベンダへの厳しい口調での指示や理 論武装での対応を心掛けた。 ②ベンダからの報告内容があまりにも技術的要素がすぎたり、ベンダのリーダクラスの報告内容が的を得てない場 合が顕著化していた。→ベンダリーダへの叱咤。及び、ベンダ上層部へリーダクラスの代替提案を仰いだ。 課題３ 新規サブシステムが複数、また、並行して案件 化されたいた ①新規案件のインフラ観点での案件推進 例）「案件A」、「案件B、「案件C」などの案件を期間内に成功裏におさめた 提案１ ベンダ作業費用が膨大となっていた ①ベンダへ見積詳細を提示させ、各作業項目を精査し、正当な作業日程を示唆し、作業費用削減に努めた。 ②「改善施策」と名乗る案件に関しては、その妥当性を加味し、作業費用半減などの判断も下した。 （内容を精査したところ、「不良品」→「普通」に戻すような施策であったため、厳しめの判断も下した。） 提案２ AWSコスト及その他費用が膨大となっていた ①未使用のAWSサービスの削除対応（突貫で構築したため、残骸などが多々あった） ②RDSなどの稼働状況を鑑み、リソースが過剰気味であったため、ダウンサイズの示唆 ③旧ディスク「汎用SSD(gp2)」→最新ディスク「汎用SSD(gp3)」への変更による性能改善及びコスト削減 ④Dynamoの「リザーブドキャパシティ」での購入提案 ※現状オンデマンドでの購入を上記購入形態に変更することで、コスト削減に努めた ⑤ジョブスケジューラのライセンス削減（JP1AJSライセンス費用のコストカット） ⑥各環境を利用時にのみ稼働させる施策 ※★★次項で説明★★
8. 7 各環境においては利用時のみ稼働させる案 4.実例紹介 現状 次期 各環境は平日の08:00-21:00にて稼働させていた 性能1環境 検証1環境 検証2環境 検証3環境 ▪補足 性能1環境：本番環境と同等（冗長性あり、インスタンスサイズ同等） 検証1,2,3環境：シングル構成、インスタンスサイズ最小 ▪説明 利用者（各ベンダなど）にAWSコンソールよりSQSを実行させ、 CloudAutomaterにより各環境のインスタンスなどを起動させ、稼働状態とし た。また、利用完了後は、同様にSQSを実行させ、各環境のインスタンスな どを停止させ、AWS利用コストを削減した 例）簡易的に利用する時のみ稼働する仕組みを 作った 例）「性能1環境」が起動される （サーバワークス社製品） 利用者（ベンダ） ポイント：AWSの仕様で【RDS】はサービス停止期間が7日を超えると自動起動してしまう。 そうすると、その後ずっと起動したままとなり、課金されてしまう。 →これを防ぐため、週一1時間程度起動させ、その後、停止する仕組みも盛り込んだ
9. まとめ 5.まとめ 要は、何かを始めるには、とにかく、お金がかかる、また、こと日本においては、「新しもの」みたいなもにお金を出 すとなると、余計に、敷居が高くなりがちな印象がある。 まずは、この「お金」をどう捻出するかを考えてみた。 「コスト削減してできたお金」であるということを印象づけることで、 よりスムーズにSRE活動に着手できるのでは？！