前職 クラウドリフトで変わった運用、 クラウドシフトでさらに変わる運用 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