Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
クラウドリフトとクラウドシフトで変わる運用/CODT2023
Search
mito
August 25, 2023
Technology
190
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
クラウドリフトとクラウドシフトで変わる運用/CODT2023
mito
August 25, 2023
More Decks by mito
See All by mito
AWS Lambdaの更新で502エラーが起きた話 / How an AWS Lambda Update Caused 502 Errors
mito201
1
100
クラウドネイティブエンジニアを育成する/CNDT2022
mito201
1
670
Backlogをサポート窓口として活用する/JBUG_Summer_2022
mito201
0
970
sudo_pip_installするときはよく考えて!/sudo_pip_install_ansible
mito201
0
1.1k
VBAで始める手のひらの上の自動化/vba_faile-coordination
mito201
0
1.3k
JANOG48_NW運用自動化の拡大/janog48_nwauto
mito201
2
310
AnsibleとCloudFormationの組み合わせでトレーニング環境を運用している話/ansible-and-cfn
mito201
2
3.4k
VBAから見たAnsiblePlaybookとの比較/diff-vba-ansible
mito201
0
600
Other Decks in Technology
See All in Technology
高負荷プロダクション環境におけるAWS Lambdaのリアル 〜スケールとコストを左右する実行ライフサイクルの技術仕様〜
maimyyym
2
680
GitHub Agentic Workflows を触ってみる
htkym
2
740
Mastering Agentic Development: Harness Engineering for Effective Coding Agents
konippi
3
590
SREの視点で考えるSIEM活用術 〜AWS環境でのセキュリティ強化〜
cscengineer
PRO
0
380
認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例
taiki45
2
410
Vibe Coding で作ったプロダクトをどう安全に動かすか / How to Safely Run Products Built with Vibe Coding
glidenote
0
760
C#未経験の僕がAIに読めるコードを書かせるまで
maguroalternative
0
330
AWS FinOps Agent 結局何が得意なの?
siromi
0
200
.NET WebAssemblyで実現するクライアントサイドAI推論:NuGetからViteまで、2つのエコシステムを繋ぐビルド戦略
yamachu
1
940
AI Agent入門〜今更聞けないAgentの話〜
hiromimaganuma
0
120
20260929_AmazonGuardDutyの検出通知メールにAWS DevOpsAgentの調査結果を追加する
yhana
1
200
地方移住と都心キャリアの両立は「金・時間・人」のリソースをフル活用すれば実現できる!〜Snowflake女子会 vol.8
snowwmn0824
0
120
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
530
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
250
[SF Ruby Conf 2025] Rails X
palkan
3
1.4k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
530
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Become a Pro
speakerdeck
PRO
31
6.3k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
700
Transcript
前職 クラウドリフトで変わった運用、 クラウドシフトでさらに変わる運用 2023.08 CloudOperatorDaysTokyo 2023 伊藤 雅人 @mito0358
前職 本セッションで話すこと クラウド移行への切っ掛けは、一部保守切れによるシステムの更改でした。 通常業務をしながら、時には障害対応しながら、ハードウェアの交換を含むシステムの更改を進めるな んてとんでもない! というわけで、まずはオンプレ環境をクラウド環境へそのまま乗せ換えるクラウドリフトを行い、その あとにコンテナ化などを含めたクラウドシフトを行う方針となりました。 現在はクラウドリフトが終わり、今後はクラウドシフトを行っていきます。 本セッションでは、クラウドリフトで得た知見を共有しながら、クラウドシフトに向けた青写真を描い ていきたいと思います。
本セッションがクラウドへの移行を検討している方、オンプレの運用に疲れてきている方にとって、 リフト&シフトへの援護射撃になれたら幸いです。 2
前職 本セッションで話さないこと 技術的な話やサービスの開発に絡む話はしません。 3
前職 本セッションで伝えたいこと 文字通りのクラウドリフトは、実施しても効果が出にくいうえに移行で大変な思いをするだけです • いくつかの運用作業にマネージドサービスを活用しましょう • お勧めはバックアップ関連の作業です 4
前職 自己紹介 氏名 :伊藤 雅人 経歴 :クラウドネイティブ内製化サービスの開発に従事。 以前は、組み込みソフトウエア開発から、生産管理や情報システム部での業務改善、 AnsibleによるNW運用自動化などを経験しました。
その他:好きな技術領域は自動化 です。 昼休みは運河沿いを散策し、カルガモを撮っています(そろそろ暑くて厳しい) 港区スポーツセンターによく行きます。 5
前職 目次 • クラウドリフトへの切っ掛け • オンプレミスからクラウドリフトすることで、 運用の何が変わったの? • クラウドリフトで苦労したこと •
クラウドリフトからクラウドシフトすることで、 運用の何が変わるの? • まとめ 6 6
前職 前職 クラウドリフトへの切っ掛け 7 7
前職 クラウドリフトへの切っ掛け クラウドリフトへの切っ掛けは、一部保守切れによるシステムの更改でした。 システムの更改をするうえで、通常の保守対応をしながらきつかった作業を上げます。 • 予算申請 • 参考となるハードウェアの選定 • ハードウェアの単価や保守費用などを調査し、調達にかかる見積もりを取得
• ハードウェアの選定 • 必要な機能、スペック、システム互換性、寿命、メーカのサポート、社内政治などから選定 • 計画の作成、調達 • 半導体不足により、調達に時間がかかる 8 更改の妥当性は、保守切れのためすんなり通ったとのこと
前職 クラウドリフトへの切っ掛け プロジェクトに関わるメンバーからは、(基本的に)賛成しかありませんでした。 以下の賛成意見がありました。 • ネガティブな賛成意見 • 設備の購入に反対! • 保守切れをむかえる度に、更改やら移行やらの議論はしたくない
• 現行踏襲をやめるきっかけが欲しい • ポジティブな賛成意見 • モダンな技術に触れるようになる(個人差あり) • 新しいスキルセットの習得が楽しみ! 9 すべての現行踏襲がわるいというわけではない (言語化できないから現行踏襲!がヨクナイ)
前職 前職 オンプレミスからクラウドリフトすることで 運用の何が変わったの? 10 10
前職 クラウドリフトで運用の何が変わったの? 運用を変えるために検討したこと、運用の変わった項目について、説明します。 • 運用を変えるために検討したこと • クラウドリフトの方針 • 責任共有モデルの認識 •
運用の変わった項目 • バッチ運用、ジョブ/スクリプト運用、バックアップ/リストア、監視、ログ管理、 運用アカウント管理、保守契約管理 • 手作業 11
前職 クラウドリフトで運用の何が変わったの? • クラウドリフトの方針 • オンプレ環境をクラウド環境へそのまま乗せ換えるといいつつ、一部のマネージドサービスを 活用します • 文字通りのクラウドリフトの場合、クラウドの価値を実感できるまで時間がかかります •
特にコストメリットに反映します • 責任共有モデルの認識 • クラウドリフトなので、例えばEC2を使うためOSのパッチ管理はユーザの責任になります • 運用がどう変わるか、調査/検討するための土台です • AWS例 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ 12
前職 クラウドリフトで運用の何が変わったの? • バッチ運用、ジョブ/スクリプト運用、バックアップ/リストア、監視、ログ管理、 運用アカウント管理、保守契約管理 • 全体に関わる内容 • 物理HWに関する作業はなくなります •
バックアップ • AWSのマネージドサービスを活用 • ツール単位のバックアップはs3へ、EBSのスナップショット取得へ • 手作業 • 構築関係の手作業 • Terraformで自動化しました。例えば、リストアに使用しています • 構築以外の手作業 • 一部の手順書作業をAnsibleで自動化しました 13 特に大きく変わった項目がバックアップです
前職 クラウドリフトで運用の何が変わったの? 参考文献 • 近藤 誠司(2021). 『運用改善の教科書』. 技術評論社 • 独立行政法人情報処理推進機構(2018).
『非機能要求グレード』 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html • その他、ITILやPMBOKなど 14
前職 特に苦労したこと 技術的な課題より、 ビジネス的な課題でした 15 15
前職 特に苦労したこと クラウドリフトを行うと決まるまでの過程です。 移行費用含め、トータルで運用コストが下がることをどう提示するかが大変でした。 • 提示が難しかった理由 • クラウドリフトに焦点を当てると、想像以上にコストメリットを出しにくいです • 手作業の自動化は、オンプレミスでも実現できるのでリフトのメリットになりにくいです
• 提示のポイント • コストは、契約の年単位ではなくシステム更改を含む期間で検討します • HW購入に関わるバックオフィスの稼働も入れましょう • オンプレミスを維持した場合(HW絡みが多い)の問題/課題もセットにします • 例えば、予備機は購入し所持したときから故障のリスクが発生します 16 ねちねちリスクを連ねます。 物品購入時、ねちねち言われたことないですか?
前職 前職 クラウドリフトからクラウドシフトすることで 運用の何が変わるの? 17 17
前職 クラウドシフトで運用の何が変わるの? クラウドリフトからクラウドシフトに移行することで、以下のメリットが受けられます。 • 更なる運用作業の消滅 • マネージドサービスにより、OSやミドルウェアなどの管理から(ある程度)解放されます • インフラの購入や破棄が容易になります •
サーバレスも検討できるようになるため、さらに管理の負担が減らせます • 新機能の追加、更新やバグ修正を素早くリリースできるようになります 18
前職 クラウドシフトで運用の何が変わるの? 運用が大きく変わるポイントは、以下の2点です。 • マネージドサービスの活用 • ECSなどでBlue/Greenデプロイを実現したいです • 意図的なサービスダウンタイムを減らしたいです •
マイクロサービス化の検討 • 障害設計を検討中 • 障害が起きたらどうするかではなく、任意のサービスがダウンしたら停止するサービス と、稼働するサービスはどれか?に注力しています • 人手で対応するサービス、継続できるサービスを予め想定しておくと、障害が発 生したときも運用しやすくなります(例えば、公共インフラなど) • 全部停止する、または大半が停止する場合は、疎結合の質を上げます 19 組織変更が必要なほどの規模ではない
前職 前職 まとめ 20 20
前職 まとめ • 一時的にでも負荷の増大が見えるときは、クラウド移行へのチャンスです • 新機能のリリース速度を上げたい、拡張性を高めたいなどといったポジティブな理由だけでは なく、ネガティブな理由も力になります • 文字通りのクラウドリフトは、実施しても効果が出にくいうえに移行で大変な思いをするだけです •
いくつかの運用作業にマネージドサービスを活用しましょう • お勧めはバックアップ関連の作業です • クラウドリフトは通過点です。クラウドシフトで、より運用しやすいサービスに変えられます 21