AWS運用を頑張らないために何が出来るのか

AWS運用を頑張らないために何が出来るのか
山﨑慎太郎 | 2021/03/20

View Slide

#jawsdays2021 #jawsug #jawsdays2021_C
自己紹介
アイレット株式会社
クラウドインテグレーション事業部 MSP開発セクション
大阪オフィス
開発エンジニア
2018/04 入社
AWSを中心とした設計・構築やバックエンド開発
社内の監視業務の改善・効率化に従事
2020 AWS APN Top Engineers
山﨑慎太郎 
Shintaro Yamasaki 
2

View Slide

今日の話
3
AWS上に構築したサーバーの運用を頑張らないために、何ができるのか、
何をしないといけないのか、改めて整理してみた話

View Slide

4
クラウドの導入設計から構築、監視、運用、
さらにはシステム開発やデザイン制作まで、
総合的なサービスをワンストップに提供。
● クラウド導入実績 2,000 社以上
● 年間プロジェクト 3,200 以上
● 8年連続 AWS APNプレミアコンサルティングパートナー
● 2019年度 APN Consulting Partner of the Year 受賞

View Slide

5
運用・保守サービス
お客様環境
運用チーム
運用/保守
お客様のAWS環境の運用保守を代行します。
24時間365日の障害対応
サーバー1台から対応可能
ニーズに合わせて
対応内容が選択可能
マネージドサービスにも対応
ここの効率化を行う運用改善チームに所属しています。
現在9,000台以上のサーバを監視

View Slide

6
構築・２次運用お客様
MSP※
お客様環境
社内サービス
MSP開発
(運用改善チーム)
利用・操作認証
情報取得・操作
利用
依頼・要望・FB
ヒアリング・提案
開発・運用保守
構築・監視運用保守
※MSP(Managed Service Provider)チーム
24時間365日の監視/障害対応を行っているチーム。
運用をサポートするための社内サービス。
● 現在20近く存在。そのほとんどをAWSで構築。
● お客様環境に対する運用の効率化のために開発
社内サービス自体に対する運用保守
この運用作業は最小にしたい
運用・保守サービス
運用チーム

View Slide

7
改めて、AWSの運用作業を削減するために
どうすればいいのか整理した

View Slide

運用を削減するメリット
1. 本業やシステム新規開発/改善に専念できる
2. コスト削減できる
○ 人による運用がある以上、人的コストが発生する。
8

View Slide

AWS (クラウド) を導入したことで
そもそもAWSを使うことで不要になったこと
9
が、不要に
1. 機器の調達・設置
2. 場所・スタッフの確保
3. 機器の資産管理・維持管理
4. 機器のリプレースなどなど

View Slide

それでも残るサーバー運用保守作業
主なEC2インスタンス運用作業
10
● サーバーアクセス管理
● バックアップ
● インスタンスリタイアメント通知への対応
● セキュリティ管理 (VPC内のセキュリティ含む)
○ IDS/IPS
○ データ保護 (EBSは暗号化する)
○ Abuse Report (不正使用報告) への対応
● OS (パッチ) 管理
● ミドルウェア管理・プロセス管理
● キャパシティ・パフォーマンス管理
○ ディスク容量管理
○ インスタンスタイプの調整
○ インスタンスのスケーリング
● 可用性・継続性管理
○ 障害時の復旧やフェールオーバー対応
今回は、主にサーバー運用にフォーカスを当てて考えてみる
正直めんどくさい...

View Slide

いわゆるクラウドネイティブにすることで運用を楽に
※ 一旦、このクラウドネイティブという言葉は忘れて「運用を楽にする
こと」を目的にどういうことをすればいいのか考えた。
クラウドネイティブという言葉自体、人や場所によって認識が違うこともある。また、今日話す内容の
全てがクラウドネイティブというわけでもない (たぶん)
参考: CNCFのよる定義 CNCF Cloud Native Definition v1.0
https://github.com/cncf/toc/blob/main/DEFINITION.md
一言で言えば
11

View Slide

運用を頑張らないための選択肢
12
1. マネージド型サービスを活用
2. コンテナオーケストレーションを活用
3. サーバー運用自動化のための各サービスの活用
4. 自作スクリプトで自動化
上から順に検討していくのが個人的にはベター

View Slide

今回の話から対象外とした選択肢例
1. 運用担当の増員
2. 運用保守の外部委託
3. やらないといけないけどたぶん大丈夫だろうということでやらない
運用削減をシステム側でなんとかできないかという視点で考える。
運用を頑張らないための選択肢
13

View Slide

マネージド型サービス = AWS側が大部分を管理しているサービス
● ユーザー側は主にデータのみが管理対象となる
● PaaS/SaaSな特徴のもの
● EC2はアンマネージド型に分類
● 品質も高く使いやすい
● 数多くのマネージド型サービスが存在
14
Runtime
Middleware
OS
Visualization
Servers
Storage
Networking
Application
Data
Application
Data
Runtime
Middleware
OS
Visualization
Servers
Storage
Networking
アンマネージド型
(EC2)
マネージド型
AWS側管理
ユーザー側管理

View Slide

15
RDS
RDBのマネージド型サービス
● OS・ミドルウェア管理不要
● 主要なDBエンジンに対応 (MySQL, PostgreSQL, SQL Server, OracleDB等)
● 自動フェールオーバー
● 定期自動バックアップ
● ディスク容量の自動拡張機能
Elastic
Beanstalk
Webアプリケーション実行・管理のためのプラットフォームサービス
● いわゆるPaaS系のサービス
● EC2やRDS、S3、ELBなどの各サービスへの深い知識不要で手軽に高可用な
Webアプリケーションを構築することができる
● 様々なAWSサービスの管理が1つのプラットフォーム上に集約され、環境
構成管理やデプロイ等の運用作業が簡素化。
以下、一部マネージド型サービス例

View Slide

マネージド型サービスの中でも、より抽象度が高く、インスタンス管
理も不要となるサービス = サーバーレスサービスも活用できる
● サーバーを意識する必要がない。
● 大幅な運用コスト削減が期待できる。
● 弊チームでもサーバーレスは多用している。
16

View Slide

● イベント駆動型コンピューティングサービス
● アイドル時のリソース確保が不要
● 柔軟なスケーリング・高可用性でありサーバー運用保守を極限まで削減
● 多くのサービスをトリガーとして利用可能
Lambda
17
DynamoDB
● Key-Valueデータベースのサーバーレスサービス
● 高スループット。オートスケーリング
以下、一部サーバーレスサービス例
S3
● オブジェクトストレージサービス
● ディスク容量の上限なし
● クロスリージョンレプリケーション機能を使ったマルチリージョン冗長化
● Cloud Front を組み合わせて静的コンテンツの配信
他にも、SQS, SNS, API Gateway, Aurora Serverless, etc…

View Slide

2. コンテナオーケストレーションの活用
コンテナオーケストレーション
= 複数のサーバーマシンを1つのクラスタという単位に集め抽象度を上げる。そし
て、コンテナベースのアプリケーションを良い具合に展開し統合管理するプラッ
トフォーム。
主に以下の作業が容易になる。
1. プロビジョニング (高い拡張性を獲得)
2. デプロイメント
3. コンテナのスケジューリング
4. トラフィックルーティング
5. ロードバランシング
6. コンテナ状態のモニタリングなどなど
18
※ 詳しく話すと長くなるので概要だけ
Application
Data
Runtime
Middleware
OS
Visualization
Servers
Storage
Networking
AWS側管理
ユーザー側管理
アプリケーションをコンテナベースにして、コンテナオーケストレーションを活用する
Application
Data
Runtime
Middleware
OS
Visualization
Servers
Storage
Networking
EC2 コンテナ
オーケスト
レーション
ツール

View Slide

2. コンテナオーケストレーションの活用
Fargate
ECS
EKS
19
AWSにおけるオーケストレーションサービス (詳細は割愛)
● AWS独自のオーケストレーションサービス
● AWS上の各種サービスとスムーズに連携できる。
● サーバーレスなコンテナ実行環境
● ワーカーノードをサーバーレスにする
● ECS, EKS両方で利用可能
● Kubernetesのマネージドサービス。
● コントロールプレーンがマネージド
補足

View Slide

1. Systems Manager (SSM) でマネージドインスタンス化
a. パッチ管理 (Patch Manager)
b. インスタンスへのアクセス管理 (Session Manager)
c. インスタンスの状態管理 (State Manager)
d. パッケージ配布 (Distributor) などなど
2. Auto Scalingでスケーリングを自動化
3. Auto Recoveryで物理ホスト障害時に自動復旧
a. システムステータスに異常がある場合。大規模障害では動かないことも
4. AWS Backupで自動バックアップ
a. 定期自動バックアップ。世代管理。
「対応するマネージドサービスがない」「非機能要件に合わない」「ベンダーロックインは
なるべく回避したい」等によりEC2インスタンスを使う場合、以下のようなAWSサービスを組
み合わせて一部運用作業を自動化できる。
AWS Backup
Auto Scaling
Systems Manager
20

View Slide

運用手順をスクリプトに起こし、運用作業を自動化する。
実行環境にはLambdaを使うことが多い。システムの1つとして含める。
1. 低コスト (アイドル時間の費用発生しない)
2. トリガーの種類が豊富
例:
● 毎日18:00に指定タグをつけたEC2インスタンスを自動停止
● 指定のS3バケットにファイルがアップロードされたら通知
21

View Slide

弊社では、一次対応手順の自動化スクリプトと処理フローを統合的に管理するプ
ラットフォームを開発。弊チーム提供の社内サービスの一つ。
複数ワークロードに対して作業自動化を容易に実装し、対応時間の短縮や品質の
均一化等を目指す。
22

View Slide

その他
構成管理
● CloudFormation, Terraform等によりコードでリソース管理 (IaC)
● OpsWorksでサーバー構成管理の自動化
● AWS Configなどでアカウント上のリソースを追従
デプロイメント (CI/CD)
● Code Buildでビルド/テスティング
● Code Deployでデプロイ
● Code Pipelineで一連のデプロイメントワークフローを構成
AWS CodeBuild
AWS CodeDeploy
AWS CodePipeline
AWS CloudFormation
AWS Config
AWS OpsWorks
23

View Slide

といっても...
「言うは易く行うは難し」
24

View Slide

つまりは、
運用を頑張らないために頑張らないといけないこともある
25

View Slide

頑張らないといけないこと
1. アーキテクチャの改善活動
運用保守作業がなるべく少なくなるようにシステムを刷新。
26
● 運用負荷を下げるためには、やはり、様々なことを設計・構築でしっかりと考慮し、
「運用でカバー」を少なくする努力が必要。
● 今あるシステムをより良い構成に移行する作業
○ 一度の移行ではなく、今よりも良い形に継続してアップデートしていく
● サービスをしっかりと疎結合に作ることで、小さい単位でアーキテクチャを改善できる
ようにする

View Slide

2. 各AWSサービスについて理解する
一番重要。トラブったときに「知らなかったから」は辛い。
27
● といっても、完全に全て知ることは不可能。運用しながらも知ることも多い。
● マネージド型サービスはまず制限事項 (上限) を把握して、限界を知る。
○ 事前にしっかりと検証・試験運用する。
● 知識がある人でないと運用が難しいので、知見の展開もしないと属人化する恐れ。
● アップデート情報も継続してキャッチアップ。
● 「Well-Architected Framework」を活用し、ベストプラクティスを知る。

View Slide

3. トラブルシューティング方法は一から整理し直す
障害発生時の調査方法が従来とは異なる
● 確認するメトリクスや手順がAWSサービスごとにばらばら
● CloudWatchやX-Ray, CloudTrailなど、原因調査を補助してくれるサービスを活用する。
● 各サービスのドキュメントにも主要なものは記載されている。
CloudWatch
CloudTrail
X-Ray
28

View Slide

4. しっかりと構成管理・デプロイ管理
複数種類のAWSサービスからなるSOAな構成をきちんと管理する。
29
● 構成やデプロイが複雑になることも。
● ボトルネックや単一障害点の発生リスクを把握する
○ リソース設定やサービス間のつなぎ方がよくなかったりすると課金額高騰も。
● CloudWatchやX-Ray、その他サードパーティを使って高い可観測性を維持する。
● CloudFormation等でコードによるリソース管理、および、インフラリソースとアプリケー
ションのデプロイを自動化。
CloudWatch
X-Ray
CloudFormation

View Slide

5. 最低限の運用作業
運用作業が0になるわけではない
Elastic Beanstalk
Lambda
RDS
プラットフォームの更新対応
DBエンジンのEOS対応ランタイムのEOL対応
30
● 全てをマネージドにすること・自動化することは難しい。
○ 自動化すべきものすべきでないものを正しく判断することも重要
● サービス固有の運用作業や、本来しないといけなかった運用作業が半強制的に必要にな
ることで、むしろ増えることも
● Personal Health Dashboardで、DBエンジンやプラットフォーム等のEOSを把握し対応
ECS EKS

View Slide

6. 自作スクリプトは自分たちで保守
陳腐化しないように保守し続ける。放っておくといつか動かなくなることも。
31
● 自作したツールに代わるAWSサービスやSaaSがあれば、可能ならそちらに移行すべき
○ 例 : バックアップの世代管理・リージョンレプリケーションの運用作業を独自ツー
ルで行っていたが、AWS Backupの機能が充実してきたことで、そちらに移行

View Slide

わずらわしい諸々の運用は、
にご相談くださいませ。
32

View Slide

1. アーキテクチャの改善活動
2. 各AWSサービスについて理解する
3. トラブルシューティング方法は一から整理し直す
4. しっかりと構成管理・デプロイ管理
5. 最低限の運用作業
6. 自作スクリプトは自分たちで保守
まとめ
33
AWSというプラットフォームをフル活用し、運用作業の簡素化・効率化へ
「頑張らない」ために「頑張る」ことを整理して考える。
運用を頑張らないために
2. コンテナオーケストレーションを活用

View Slide

まとめ
34
“AWSのマネージドなソリューションで
クラウドネイティブなアーキテクチャをクリエイトし
NoOpsでアジリティの高いサービスマネジメントで
DXをアクセラレートさせよう”

View Slide

AWS運用を頑張らないために何が出来るのか

AWS運用を頑張らないために何が出来るのか

Shintaro Yamasaki

More Decks by Shintaro Yamasaki

Other Decks in Technology

Featured

Transcript