株式会社スリーシェイク 手塚 卓也 Container サービスと Toil と

Copyrights©3-shake Inc. All Rights Reserved. 2 自己紹介 自治体やデータベースマーケティング会社でのインフラ設計 /構築 /運用を主に経験し、2018 年 10 月に スリーシェイクに Join。 スリーシェイク Join 後は Google Cloud / AWS / kubernetes / ServiceMesh など様々な技術的アプローチを駆使し、 大手からベンチャー等規模を問わず様々な組織に対して SREの コンサルティングや実践を行う。 2020年からは事業部長として総勢 30名のSREエンジニアのマ ネージメント、技術広報、採用、組織構築を担当 趣味はボクシング観戦 ※ 日曜日の昼間は WOWOW 見ながら一人で熱狂してます ... 手塚 卓也

Copyrights©3-shake Inc. All Rights Reserved. 3 1. About スリーシェイク 2. Container サービスと Toil と 3. まとめ アジェンダ

1. About スリーシェイク

Copyrights©3-shake Inc. All Rights Reserved. 5 About スリーシェイク SRE 支援 / 技術支援 サービス Sreake セキュリティ脆弱性診断 サービス Sreake Security クラウド型 ETL / データ パ イプライン サービス Reckoner ハイスキル フリーランス紹 介サービス Relance Reckoner はクラウド型 ETL / データパイプライン サービスで す。 データベース・ストレージ・アプリ ケーションなど、あらゆるデータを 統合・連携することで、データを活 用したビジネス変革に貢献しま す。 Sreake Security は経験豊富な セキュリティ専門家が貴社の課題 に合わせたセキュリティ対策を支 援するサービスです。 Sreake は金融・医療・動画配信 ・AI・ゲームなど技術力が求めら れる領域で豊富な経験を持つ SRE が集まったチームによる 技 術支援サービスです。戦略策定 から設計・構築・運用、 SaaS 提供 まで、幅広い領域をサポートしま す。 Relance は、プロの現役エンジニ ア集団が最適なエンジニアを紹介 するフリーランス エンジニア紹介 サービスです。 技術支援や、 1on1 での定期フォ ローなど、参画後も高いパフォー マンスを維持し続けられる体制 を 提供しています。

Copyrights©3-shake Inc. All Rights Reserved. 6 Securify ◯Securify（セキュリファイ）とは Securify（セキュリファイ）は、診断対象を登録するとクラウド上で脆弱性診断を実施、診 断結果一覧と改善方法を分かりやすく提示します ◯Securify開発における想い 企業が、開発・リリーススピードを落とさず、手軽に（費用・時間をかけず）社内でセキュリ ティ診断を実施（＝DevSecOpsを実現）し、サービスを提供することが、企業・エンドユー ザーの利益を最大化していくことになると考えています。これを可能にするツール 「Securify（セキュリファイ）」を開発 Beta 版 無償提供実施中！！

Copyrights©3-shake Inc. All Rights Reserved. 7 本日お話する内容 SRE における 信頼性などその他の要素 SRE における Toil にのみフォーカスしたお話 AWS の Container サービスをどのような視点で選定しているかについて 話すこと 話さないこと 詳細なシステムアーキテクチャなど

2. Container サービスと Toil と

Copyrights©3-shake Inc. All Rights Reserved. 9 SRE における Toil とは? what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. 参照: https://sre.google/sre-book/eliminating-toil/ Toilとは何でしょうか。Toil(労苦) とは、生産サービスの運営に関連する仕事のことで、 手作業で、反復的で、自動化でき、戦術的で、永続的な価値がなく、サービスが成長するにつれて直線的に拡大する傾向があるもので す。

Copyrights©3-shake Inc. All Rights Reserved. 10 Toil 削減の為の Step Step 1 Toil の 特定 Toil の計測 Toil の削減 Step 2 Step 3 Toil の性質をもったタスクを特定 する 例: ) Jiraでチケット管理してKPTで 振り返り その Toil に対してどの程度の時間を 費やしているのかを計測する 例: ) チケットの稼働時間を適切に計 測 Software エンジニアリング等を 使って自動化させる 例: ) Lambdaとか作って自動化! このプロセス結構辛いぞ...

Copyrights©3-shake Inc. All Rights Reserved. 11 Toil 削減って簡単に言うけど、めっちゃ体力いるやんって話 自動で色々やってくれるロボットは欲しいけど、ロボットを作りたくはないってコト ここだけ欲しい...!! 頑張って作って、 自動化!!

Copyrights©3-shake Inc. All Rights Reserved. 12 要は本質的になろうよという話 what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. 参照: https://sre.google/sre-book/eliminating-toil/ Toilとは何でしょうか。Toil とは、生産サービスの運営に関連する仕事のことで、 手作業で、反復的で、自動化でき、戦術的で、永続的な価値がなく、サービスが成長するにつれて直線的に拡大する傾向があるもので す。 In SRE, we want to spend time on long-term engineering project work instead of operational work. Because the term operational work may be misinterpreted, we use a specific word: toil. SREでは、運用業務ではなく、長期的なエンジニアリング・プロジェクト業務に時間を使いたいと考えています。運用作業というと誤解 される可能性があるので、具体的な言葉として「Toil」を使っています。

Copyrights©3-shake Inc. All Rights Reserved. 13 運用観点で重要となる Workload 選定 App Runner ECS / EKS Self Hosted Managed Unmanaged AWSには多様な Workload 実行基盤の選択肢がありますが ... Managed なサービスでの実現性を始めに検討した上で徐々に Unmanaged なサービスへ降りていくようなイメー ジで Workload を選定するのも一つ。 ECS / EKS Fargate Lambda EC2

Copyrights©3-shake Inc. All Rights Reserved. 14 個人的まとめ EKS ■ 良いところ ● 強力な OSS の恩恵を受けることが出来る ○ 監視 → Prometheus / Grafana ○ CI/CD → Tekton / ArgoCD etc… ○ ServiceMesh → Istio ○ Chaos Test系のTools → Litmus Chaos / Chaos Mesh ● ECSと比較するとAnywhere戦略は取りやすい ○ 複数サービスを複数のクラウドで運用しているケースだと仕組みを共 通化出来るのでメリットが大きい ■ 嫌なところ ● クラスタのUpdateとかはやっぱり運用負荷は高くなりがち ● Developer に向けてはハードルが非常に高い ?

Copyrights©3-shake Inc. All Rights Reserved. 15 個人的まとめ ECS ■ 良いところ ● システム運用に必要な「仕組み」が AWS上で既に用意されている ○ Auto Scale や 回復性の機能群が用意されていてそこに乗っかれるのは 大きなメリット ○ ECS Fargate はGAになってからも期間が長く安定感があって素敵 ■ 嫌なところ ● コンポーネントの全てが AWSに依存しやすい ○ ちゃんとやろうとすると、 CD周りはCodeDeploy、ServieMesh は AppMesh みたいな感じで限定されやすい ○ 全てを「クラウドリソース」として扱う感じになるので、 Terraformとの境界 迷う ● Configmapの機構がないのは地味に辛い ○ NginxのConfig食べさせられないので、 Image BuildしてECRに上げるみ たいなのが面倒。いい方法あれば誰か教えて ...

Copyrights©3-shake Inc. All Rights Reserved. 16 ケーススタディ ※ 大規模システム / 大規模組織での事例 ECS を中心とした技術選定 で MicroService 開発 2018 2019 2021 2020 既存 サービス Lift-and-Shift 完了 AWS EKS が東京リージョンに登場 → k8s をCoreとする方向転換 AWS 新規 サービス ローンチ AWS 新規サービス ローンチ GCP 新規サービス ローンチ AWS Google Cloud Daysにて発表した内容から引用 : https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21?talk=d3-gl-25 デジタル組織の立ち上げ あるお客様の Workload 選定の事例 大規模サービスのプラットフォーム開発 GCP

Copyrights©3-shake Inc. All Rights Reserved. 17 チームとして 「何を大切にするか」を理解することが大事 構築の手間はどの程度？ どの程度運用の手間がかかるか ? 責任境界はどこか? 信頼性はどこまであるのか？ 監視実装はどの程度しやすいか？ Anywhere 戦略が取れるか？ 自分たちのチームにとってどの程度扱 いやすいのか？ 仕組みを共通化させやすいか？ 組織全体としてガバナンスが効きやすいか？ エンジニアにとって魅力的か？ どの程度障害解析はしやすいか ?

Copyrights©3-shake Inc. All Rights Reserved. 18 チームとして 「何を大切にするか」を理解することが大事 構築の手間はどの程度？ どの程度運用の手間がかかるか ? 責任境界はどこか? 信頼性はどこまであるのか？ 監視実装はどの程度しやすいか？ Anywhere 戦略が取れるか？ 自分たちのチームにとってどの程度扱 いやすいのか？ 仕組みを共通化させやすいか？ 組織全体としてガバナンスが効きやすいか？ エンジニアにとって魅力的か？ どの程度障害解析はしやすいか ?

Copyrights©3-shake Inc. All Rights Reserved. 19 要は本質的になろうよという話 what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. 参照: https://sre.google/sre-book/eliminating-toil/ Toilとは何でしょうか。Toil とは、生産サービスの運営に関連する仕事のことで、 手作業で、反復的で、自動化でき、戦術的で、永続的な価値がなく、サービスが成長するにつれて直線的に拡大する傾向があるもので す。 In SRE, we want to spend time on long-term engineering project work instead of operational work. Because the term operational work may be misinterpreted, we use a specific word: toil. SREでは、運用業務ではなく、長期的なエンジニアリング・プロジェクト業務に時間を使いたいと考えています。運用作業というと誤解 される可能性があるので、具体的な言葉として「Toil」を使っています。 自分たち「サイズ」の技術選定をして価値あるエンジニアリングをしていこう

4. まとめ

Copyrights©3-shake Inc. All Rights Reserved. 21 まとめ ❖ Toil を削減していく志は素晴らしいけど、リソースが足りない状況ではそもそも Toil を削減までのプロセスや作業自体が Toil(労苦) になる ❖ Toil の判断軸はあるが、 何が Toil になるかは自分たちの組織や実現したいこと 次第でもある。まず は測定して適切に見極めていこう ❖ システム特性 / チームのレベル / 企業の方針 / サービスの成長性などに合わせて、システム選定を 行い、「価値ある仕事」を増やす為のシステムを模索 していこう

Thank you

Copyrights©3-shake Inc. All Rights Reserved. 23 We are Hiring!! スリーシェイクでは一緒にSRE界隈を盛り上げてくれる仲間を募集中です！ もしご興味をお持ちでしたら詳しいお話をさせてください！ 専用フォームを用意しましたので、以下QRコードよりご登録お願いします。 【カジュアル面談登録フォーム】 https://hrmos.co/pages/threeshake/jobs/E_9999/apply ※フォームの都合上、必須となっている項目がいくつか存在します。ご了承ください。