2026-02-28_まずはここから_AWSエンジニアへの第一歩_ネットワーク_コンテナ_監視.pdf

Transcript

1. ここから！AWSエンジニアへの第⼀歩 クラウドゼミナール：ToyoStar☆ ネットワーク、コンテナ、監視
2. 若者にクラウドを広め、⽇本のクラウドリテラシーを⾼めたい！ ⽇本の未来をもっとワクワクするものにしたい そのために、ITの⼒、特にパブリッククラウドの活⽤が有⼒な⼿段 の⼀つであると私たちは考えています。 でも、クラウドって難しそうだし、どこから学べばいいかわからな い…。 そんな⼤学⽣に向けて、私たち若⼿エンジニアが、少し先を ⾏く先輩としてクラウドの学びをサポートします！ 「クラウドって⾯⽩い！」そう思える⼈を増やしたい。 ⼀緒に学ん で、⽇本の未来をもっと盛り上げていきましょう！ 私たちについて
3. ⼤学⽣＆若⼿エンジニア向けの無料クラウド勉強会 主な活動内容 • そもそもクラウドって何？ • どういうところで活⽤されているの？ • どうやって学べばいいの？ IT勉強会プラットフォーム 「Conppass」上で定期開催 https://connpass.com/user/ToyoStar/open/ というような⽅を対象として、クラウド‧AWS を超基本から学べる勉強会を開催しています。
4. 新潟出⾝‧SIer勤務3年⽬のエン ジニアです! 普段はAWS上のAPI‧バッチアプ リケーションの設計や実装を⾏っ ています。 ⼀緒にクラウドについて勉強しま しょう! ⾃⼰紹介 河本 瞬 品⽥ 遵詞 間世⽥ 秀 SIer勤務2年⽬のITエンジニアです 主に基幹システム‧インフラ構築 業務に従事しています。 私⾃⾝も学び続ける⽴場ですが、 皆さんと⼀緒に成⻑していけるよ うな講義を⽬指しています。 Shun Kawamoto Junji Shinada Shu Maseda Sa某SIer勤務3年⽬のエンジニ ア。社内AWSシステムの運⽤を ⾏っています。 好きなAWSサービス：AWS Transit Gateway 成⿂になるべく奮闘中。
5. まずはここから！ AWSネットワーク
6. AWS周りのネットワーク
7. もう少しグラフィカルにすると‧‧‧
8. AWS Global Network AWS Global Networkは、AWSが所有‧運⽤する プライベートなグローバルネットワークインフラです。 • リージョン：世界中の物理的な拠点 • アベイラビリティゾーン：⼀つのリージョン内に存在す る物理的に分離された複数のデータセンター群
9. Availability Zone
10. Region
11. Internet GatewayとSubnet VPCのインターネットの出⼊り⼝は、Internet Gatewayを作成することで実現できます。 Internet Gatewayへの直接ルートを持つサブネットを、Public Subnet（緑）と呼びます。 Internet Gatewayへの直接のルートを持たないサブネットを、Private Subnet（⻘）と呼びます。 Subnetとは • VPC内のIPアドレス範囲を分割したもの • EC2インスタンスなどのAWSリソースを作成可能
12. Webサーバをどこに置くか？ Public SubnetにWebサーバを置く構成は最も簡素な構成ですが、 インターネットから直接アクセス可能なため、多層防御の観点から推奨しません。
13. Webサーバをどこに置くか？ Private SubnetにEC2を配置する構成の場合、Elastic Load Balancer‧NAT Gatewayが必要になります。 外からEC2通信する：⻘⽮印 EC2から外へ通信する：⾚⽮印
14. (⼩話)Regional NAT Gateway 従来は、冗⻑化構成の場合、各AZにNAT Gatewayが必要でした。 2025年11⽉19⽇にRegional NAT Gatewayが発表されたことで、 1つのReginal NAT Gatewayへ集約および、NAT Gateway⽤のPublic Subnetが必要なくなりました。
15. クラウドリソースの操作はAPIで⾏う すべてのAWSサービスへのアクセスは、最終的にHTTPSベースのAPIリクエストに変換されます。
16. マネジメントコンソールへのアクセス マネジメントコンソール（マネコン）は、AWS Global Network上に存在しています。 AWS Global Networkは、AWS管理のネットワークですが、インターネットと接しています。 ⾃宅やデータセンタ内の開発者はそれぞれのインターネット出⼝からマネコンへアクセスすることができます。 マネコンログイン後、同じGlobal Network内にある様々なAWSリソースを作成することができます。 AWS Global Network
17. ここまでの振り返り
18. VPC Endpointの役割 Public Subnet内のリソースは、Internet Gatewayを通してVPC外の様々なAWSリソースにアクセス可能です。 ⼀⽅Private Subnet内のインターネットへの経路を持たない場合（NAT Gatewayがない場合）のリソースは、 VPC外リソースにアクセスできないためVPC Endpointが必要になります。
19. EC2へのログイン⽅法 EC2へログインするには、様々な⽅法があります。代表して1つご紹介します。 • マネジメントコンソール経由の接続
20. マネジメントコンソール経由の接続 厳密には、EC2 Instance ConnectやEC2シリアルコンソールといった⽅法もありますが、 今回はSystems Manager Session Managerをご紹介します。 Session Managerは、EC2へ安全に接続‧管理できるフルーマネージド型のAWSサービスです。 SSHキーや踏み台サーバーを管理する必要がなく、インバウンドポートを解放せずに、 ブラウザから簡単にサーバーへアクセスできます。
21. Session Managerでの接続要件 Session Managerは、VPC外サービスなのでInternet GatewayもしくはEndpoint経由の接続が必要です。 必要なEndpoint3種 • ssm:Systems Manager接続⽤ • (ec2messages:Agentからサービス呼び出し⽤) • ssmmessages:インスタンス接続に必要 EC2が持つIAM Role(役割)に EC2がSystems Managerを利⽤するための権限 “SSMManagedInstanceCore”の追加も必要
22. Session Managerでの接続要件 ⽮印のとおり、EC2からはアウトバウンド通信のみ、インバウンドは解放不要なところがメリットの1つです。
23. Session Managerでの接続要件 ⼀⽅で、VPC Endpoint⽬線だとEC2からのインバウンド通信があるため、 VPC EndpointのSecurity Groupでは、VPCからのインバウンド443ポートを許可する必要があります。
24. 本⽇のまとめ
25. AWSで学ぶコンテナ⼊⾨ ToyoStar☆ 品⽥遵詞
26. AWSで学ぶコンテナ⼊⾨ アジェンダ 1. コンテナ & Docker⼊⾨ 2. コンテナオーケストレーションサービスの必要性とAmazon ECS 3. Kubernetesの概要とAmazon EKS 超⼊⾨ 〈おことわり〉 ‧Google Cloudの内容はほぼございませんm(_ _)m ‧Kubernetesの実装については紹介ございません。
27. コンテナとは「ゲームのカセット」のようなもの 開発者のローカルPCでも、 AWS上でも、同じ「イメージ」があれば同じように動作 イメージ(Image): アプリケーションと依存関係を まとめたパッケージ コンテナ(Container): イメージを動かしている実態
28. コンテナとは、コマンドを実⾏するための領域 コンテナの特徴3つ 1.コンテナはイメージから作る Image 2.個々のコンテナは互いに 独⽴している 3. コンテナランタイムが あればどこでも動く Python 3.9 Python 3.13
29. Dockerの基本サイクルと⽤語 Dockerfile Build Image Registry Run ‧設計図 ‧構成をコード化 ‧実⾏に必要な ファイルが固められた パッケージ ‧イメージを保存 ‧コンテナ実⾏ ‧パッケージ⽣成 を実⾏(後述)
30. コンテナ型仮想化ソフトウェアの代表 Dockerとの周辺技術 仮想化ソフトウェアおよびその周辺技術 ✓ Docker Desktop ✓ Docker Hub (Amazon ECR) ✓ 企業利⽤の場合は Rancher Desktop
31. Dockerfileの実装 ‒ コンテナの設計書 OS選択やライブラリのインストール⼿順をテキストファイル1枚に記載。 誰でも同じ環境を再現可能 実⾏されるタイミング 👆Dockerfileの基本は10⾏以内で実装可能 Build Run 簡単なアプリであれば、Dockerfileのみの追加実装でコンテナ化可能
32. サンプルWebアプリケーションでもDockerfileは10⾏以内で実装可能 サンプルアプリケーション メッセージを保存 する機能 app.pyと Dockerfile https://catalog.us-east-1.prod.workshops.aws/workshops/f5abb693-2d87-43b5-a439-77454f28e2e7/ja-JP EKS(後述)のAWS公式ハンズオン資料 backendの Dockerfile 7⾏! ※ 2⽉末時点、確認できず
33. AWSで学ぶコンテナ⼊⾨ アジェンダ 1. コンテナ & Docker⼊⾨ 2. コンテナオーケストレーションサービスの必要性とAmazon ECS 3. Kubernetesの概要とAmazon EKS 超⼊⾨
34. 【再掲】コンテナとは、コマンドを実⾏するための領域 コンテナの特徴 1.コンテナはイメージから作る Image 2.個々のコンテナは互いに 独⽴している 3. コンテナランタイムが あればどこでも動く Python 3.9 Python 3.13 今度はここの話です👆
35. AWS上のコンテナオーケストレーションサービス：Amazon ECS https://youtu.be/stpz_SNiWmA ‧OSのパッチ‧アップグレード不要 ‧他のAWSサービスとのネイティブ統合 ‧ログ‧メトリクス‧イベントをサポート ‧選択可能な実⾏環境(データプレーン) Amazon Elastic Container Service (Amazon ECS) 特徴 Fargate EC2 コンテナオーケストレーションサービス…? 👀
36. コンテナオーケストレーションサービスの必要性 https://www.youtube.com/watch?v=CGfRsyQW1rE 先ほどの例は 3種のコンテナを必要としていた Front, Back, DB で3種のコンテナ オーケスト レーションサービス = コンテナ管理者 (のイメージ) FrontとBackは2つずつ を保ちなさい Front Back DB Dockerの責務は単⼀サーバー内、 複数コンテナの管理はしていない
37. コンテナオーケストレーションサービスの必要性 コンテナ管理者 (のイメージ) FrontとBackは2つずつ を保ちなさい Front Back DB これがオーケストレーションサービス 👉
38. AWS上のコンテナオーケストレーションサービス：Amazon ECS https://youtu.be/stpz_SNiWmA ‧OSのパッチ‧アップグレード不要 ‧CodeDeploy等 他のAWSサービスとのネイティブ統合 ‧ログ‧メトリクス‧イベントをサポート ‧選択可能な実⾏環境(データプレーン) Amazon Elastic Container Service (Amazon ECS) 特徴 Fargate EC2
39. AWSで学ぶコンテナ⼊⾨ アジェンダ 1. コンテナ & Docker⼊⾨ 2. コンテナオーケストレーションサービスの必要性とAmazon ECS 3. Kubernetesの概要とAmazon EKS 超⼊⾨
40. コンテナオーケストレーションサービスの必要性 コンテナ管理者 (のイメージ) FrontとBackは2つずつ を保ちなさい Front Back DB これがオーケストレーションサービス 👉
41. コンテナオーケストレーションサービスのオープン化の必要性 FrontとBackは 2つずつを 保ちなさい Front Back DB クラウドプロバイダー A Front Back DB Keep two front and two back containers クラウドプロバイダーG オーケストレーション⽅法がプラットフォームごとに異なるとすると、 マルチクラウド(マルチプラットフォーム)対応が困難
42. Kubernetes 読み⽅：クーバネティス, クバネティス 等 略：k8s 特徴 ‧もともとGoogleが開発、OSS化されている ‧Kubernetes⾃体が分散システム ‧学習コストは⼤✏ ‧(結果として)⼤規模システム向け OSSのコンテナオーケストレーションサービスであるKubernetes
43. Kubernetesのコンポーネント概要 管理コマンド 発⾏ リクエスト受付 Podの割当 Pod等の 状態保持 Control Plane-Podと のやりとり仲介 Pod ≒ コンテナ Kubernetesでは複数のコンポーネントが協調してコンテナを管理する
44. Amazon EKSは Control PlaneをAWSマネージドに管理するサービス Amazon Elastic Kubernetes Service (Amazon EKS) が管理 可⽤性はデフォルトで保たれる 開発者が管理 Dockerfile以外にmanifestのyamlを実装できればEKSへのデプロイができます!
45. まとめ コンテナ⼊⾨ 1.コンテナはイメージから作る 2.個々のコンテナは互いに独⽴している 3. コンテナランタイムがあればどこでも動く コンテナの特徴 AWSのコンテナオーケストレーションサービス Dockerfileの実装 ECS, AWSマネージドなコンテナデプロイが可能(Fargate) EKS, AWSにおけるKubernetes利⽤ Icons from Flaticon: • document - Freepik • build - juicy_fish • docker - Hopstarter • shipping - Afian Rochmah Afif • automation - Iconjam
46. https://github.com/aws-samples/dify-self-hosted-on-aws/blob/main/imgs/architecture.png 〈補⾜〉dify-self-hosted-on-awsの中⾝を覗いてみる クラスター ECSで⼗分実務で使える構成を つくることができる!
47. 〈補⾜〉Dockerの基本サイクルと使⽤ツール群 ※ Docker Desktopで開発環境を作成 Dockerfile Build Image Registry Run ‧設計図 ‧構成をコード化 ‧実⾏に必要な ファイルが固められた パッケージ ‧イメージを保存 ‧コンテナ実⾏ ‧パッケージ⽣成 を実⾏(後述) Docker Engin エディタ等で作成 Docker Engin, Docker compose (in Docker Desktop) Docker Hub, Amazon ECR Icons from Flaticon: • document - Freepik • build - juicy_fish • docker - Hopstarter • shipping - Afian Rochmah Afif • automation - Iconjam
48. AWS監視（CloudWatch）⼊⾨
49. • Amazon CloudWatchとは （モニタリングとオブザーバビリティ） • AWSにおける監視の考え⽅ • 監視基盤の全体像 • クラウド監視アーキテクチャの整理（4つのレイヤー） アジェンダ
50. Amazon CloudWatchとは Amazon CloudWatch
51. Amazon CloudWatchの位置づけ
52. モニタリングとオブザーバビリティ
53. システムの状態把握に必要な「3つの柱」
54. CloudWatchの機能⼀覧
55. AWSにおける監視の考え⽅
56. 監視基盤の全体像(デジタル庁：リファレンスアーキテクチャ)
57. 監視アーキテクチャの整理観点 「どのレイヤーを」「どのデータ形式で監視するか」という観点から、監視アーキテクチャを4つのレイヤーで整理
58. 監視基盤（コンピュート/OSレイヤー監視（EC2詳細監視）） 要件‧要望 1. EC2インスタンスOS監視：CPU使⽤率などのAWS標準メトリクスに加え、メモリ使⽤率やディスク使⽤率を監 視し、リソース不⾜によるシステム停⽌を未然に防ぐ。 2. プロセス死活監視：特定のプロセスが稼働しているかを監視し、ダウン時に即座に検知する 3. ⼀元管理：多数のサーバに対する監視エージェントの設定を統⼀し、管理コストを削減する
59. 監視基盤（ネットワークレイヤー監視（通信可視化）） 要件‧要望 1. 通信トラブルの迅速な切り分け：接続できない事象が発⽣した際、セキュリティグループやNACLで拒否されて いるかを即座に特定する。 2. セキュリティ監査：不正なポートスキャンや予期せぬ外部通信の痕跡をログとして保持する。 3. トラフィック傾向の把握：VPC内の通信量の増減を把握する。
60. 要件‧要望 1. リアルタイムエラー検知：アプリケーションログに出⼒される「ERROR」「Exception」等のイベントを検知 し、即時に通知を⾏う。 2. ログの⼀元管理：EC2へのSSHログインや各サービス個別の管理画⾯に依存せず、CloudWatch上でログを横断 的に閲覧‧検索できるようにする。 3. トレンド分析：エラー発⽣件数の推移を時系列で可視化し、リリースや設定変更による影響を把握する。 監視基盤（アプリケーションレイヤー監視（ログ＆エラー検知））
61. 要件‧要望 1. サービスの可⽤性維持：AWSマネージドサービス（RDS, ELB等）のダウンや性能劣化を検知する。 2. リソース枯渇の未然防⽌：ストレージ容量や接続数など、スケーリング限界やクォータ（制限）への到達を事前 に検知する。 3. ユーザー体験の監視：ロードバランサーの応答速度など、エンドユーザーへの影響を監視する。 監視基盤（マネージドサービスレイヤー監視（AWSリソース））
62. まとめ 1. Amazon CloudWatchとは収集‧可視化‧アクションを統合し たフルマネージドサービスのこと。 2. データ収集の際は「メトリクス‧ログ‧トレース」の3つの柱を 意識すること 3. 監視を設計する際は、「OS‧ネットワーク‧アプリ‧マネージ ドサービス」の4つのレイヤーを意識すると全体像が掴みやす い
63. 参考⽂献
64. クロージング
65. クロージング 最後にアンケートにご協力をお願いいたします（所要時間 2分程度） 本日はご参加いただきありがとうございました！！ よければXのフォローもお願いします！ @ToyoStar_cloud