AWS 定番業務システム14パターン設計ガイド(2章)
2章をまとめてみました。
キーワード
オンプレミス環境のデータをバックアップ
- オンプレミスのサーバからS3にはAPI接続
- 転送料金はS3への受信は無償、送信は有料
- バージョニング、ライフサイクル、暗号化
2)EC2を使ったDBバックアップ
3)ゲートウェイ保管型ボリュームの利用
- バックアップ目的
- オンプレにボリュームストレージを作成
- EBSスナップショット形式でS3自動同期
- 最大32個のボリュームストレージを作成
- ストレージ容量1G~32TBの範囲
用途に合わせたファイルサーバ
1)S3をファイルサーバ利用した際の注意点
- PGからアクセスするにはREST APIを利用
⇒アプリ制約でREST API不可もある
- ファイルの排他制御ができない
- S3の上書き処理が結果整合性モデルで動作
⇒複数同時の読書きは意図しない更新結果に
2)EFSのマウントと利用パターン
3)ゲートウェイキャッシュ型ボリューム
- ファイルサーバ目的
- オンプレのストレージにボリュームを作成
- メリット:S3利用で拡張が容易と低コスト
- キャッシュミスの際、データ転送料金発生
- 低頻度のファイルはレスポンス低下となる
まとめ
BK手法とファイルSV選定のポイント
AWS 定番業務システム14パターン設計ガイド(1章)
1章の部分をインプットのやり方でやってみた。
テーマ
設計ポイントとは?
目的
各サービスの設計を理解するため
キーワード
1)ELB設定時の注意点
- WebサーバはELBのリクエストのみ受付
- Cookie情報を基に同一サーバに振り分ける
- 個々のWebサーバでSSL証明書管理が不要
- 正常性を監視するヘルスチェック
- レスポンス時間に応じたタイムアウト設定
2)RDS利用時の注意点
- 自動バックアップの保持期間1〜35日
- メンテはマルチAZ利用でダウンタイム減
- マルチAZ利用はデータ更新処理が長い
- DBとEC2が異なるAZにあるとアクセス遅延
3)CloudFrontの参照先振り分け機能
- URLのワイルドカード指定が前提
4)ストレージI/O帯域の対策
- EC2インスタンスのOP:EBS最適化
- EBSボリュームのOP:プロビジョンドIOPS
5)Auto Scalingグループ作成
- 予測可能や予測不可のスケーリングポリシー
- EC2インスタンス購入オプションでコスト減
6)Auto ScalingグループでのAMI作成
- デプロイ方法はアプリのリリース頻度で決定
- インスタンス終了に備えデータをEBSへ退避
7)EC2インスタンスを自動復旧
- CloudWatchでStatusCheckFailed_System
- インスタンス自動復旧はAuto Recovery
8)DRに自動切替えするにあたって
まとめ
可用性、性能、CostがWebシステム設計の観点
すべての知識を「20字」にまとめる 紙1枚! 独学法
この本を読んで、まとめてみました。
学んだことを忘れないために必要なのは
思考整理する上で大事なのは考え抜くこと。これにより本質をつかむ力が付く。本質は、シンプルで端的な言葉で表現すること。
- 目的の明確化
- 思考整理
- 端的な要約
インプット
以下の項目に沿っていく。
1.テーマ
- テーマを決める
2.目的
- 目的はシンプルにする
- 20字にする
3.キーワード
- 16個以上キーワードを書く
- 要約して20字前後の1行でまとめる
- キーワードが一通り書けたら、情報を整理して考えをまとめるために、キーワードをグルーピングする
4.まとめ
- 16個以上のキーワードを20字の一言でまとめる
アウトプット
アウトプットとは、人に説明できること。これを達成するには以下の通りです。
前準備として学習の目的を明確にする。
- 1)誰のためなのか(Who)
- 2)どんな問題または願望なのか(Problem/Wish)
- 3)目的を達成できる質問は(Purpose/Question)
次に、以下の項目に沿っていく。
1.テーマ
- テーマを決める
2.キーワード
- 各問い(Q1、Q2、Q3)に対して、3つキーワードを書く
- 各問いが書けたら全体を俯瞰し、問い同士の連携に不備がないか確認する
- Q1.なぜ参加したのか(Why)
- Q2.何を学んだのか(What)
- Q3.今後にどう活かすか(How)
3.まとめ
- 目的達成の答えとなる
- 20字におさえる
JAWS DAYS 2019
はじめに
このイベントの初心者が参加してみた。知っておけば何も苦労しないことも知らないと...
- 参加しようとチケットを取るのにまさかのキャンセル待ち状態。ギリギリまでチケットが取れずに焦る
- セッションを決めるのも大変、聞いてみたいセッションが多くて迷い、結局セッションのテーマが被らないようセッションを選ぶことにした。心残りはハンズオンが受けれなかったこと
- 当日、会場に入って受付で名刺を求められるが名刺は持っていない。みんなは名刺を渡す中、自分は名前と電話番号を書く。次回は持っていこう...
- じつはセッション中のスライド撮影は可能(知らなかった)。登壇者にもよるが資料展開がない場合もある。また資料が展開されても内容が削られる場合もある
- 休憩時間があるようでない。移動や席取りで時間を取られる。昼休みもランチセッションというものがあって聞きながらランチ
- 休憩時間は登壇者と会話できる。名刺交換もできる
選んだテーマ
サーバレス(ブロックチェーン)、セキュリティ、Infrastructure as Codeを聞いてみたいセッションだった。
- サーバレス
- セキュリティ
- ハイブリッドクラウド
- Nutanix
- Infrastructure as Code
- 働き方
サーバレスで動かすトークン発行プラットフォーム
ブロックチェーンとは
- ブロックチェーンは、ビットコインなどの仮想通貨を実現する技術として登場した
- 重要なデータをネットワーク上で共有しながら管理する技術
- 従来の銀行システムと比べ、ブロックチェーンの強みは、中央集権化の防止、取引コストの削減、情報の改ざんが困難
Ethereum(イーサリアム)
- イーサリアムとは Vitalik Buterin 氏によって開発された、プラットフォームの名称です
- ブロックチェーン上に契約内容を記録し、期日になると自動で契約内容を実行してくれるシステムを実装できることです。このシステムをスマートコントラクトと呼びます
- スマートコントラクトの機能を利用して、分散型アプリケーション(英: Decentralized Applications、略称: DApps)を構築することができます
- DApps とは、企業や銀行などの中央管理者がいなくても稼働するアプリケーションのことです
- DApps はアプリケーションを利用する参加者全員がデータを分散管理し、仕様変更などの意思決定に関わることができます
Slack(スラック)
- スチュワート・バターフィールドによって開発された、チームコミュニケーションツール
- UIとして使っている
SimplexToken(仮想通貨)を発行して社内で利用してもらう
最小限の機能
- 残高照会
自分はどのくらい仮想通貨を持っているか確認できる
- トークン受取
何かしらのトリガーで仮想通貨がもらえる
登場したAWSサービス
トークン発行をベースとしたプレゼンサポートアプリの開発
今回導入したAWSサービス
まとめ
- 初めてブロックチェーンの分野に触れてみた。用語や仕組み、この技術をどのように活用し何ができるのかを知らなかった。このセッションで、どんな活用方法があるかを知った。また、どんな技術かを調べるきっかけとなった
- 前半の構成は、API Gateway + Lambda + DynamoDB を使った一般的なサーバレス。イーサリアムやスラックの動きはスライドで想像ができた
- 後半の構成は、Vue.jsのSPAをS3にホスティングできることやCloudFormation(SAM)を使ってLambda, API Gateway,DynamoDB のリソースをひとまとめに管理 (作成 / 更新 / 削除) することができることは知らなかった
AWS Serverlessを活用したサービス監視
なぜサーバレスで創るのか
- 常時データを送信しても良いエンドポイントの提供
- サーバを常時起動せずとも実行できるランタイム環境の提供
- サーバ不要な管理レス、運用、費用面での大きなアドバンテージ
監視サービスのコンポーネント
データ収集
- Agent:サーバーの状態を監視する
- Monitoring:サービスの提供状況を監視する
- Error:サービスのエラー状況を監視する
データストレージ
- Cloud Watch
- DynamoDB
- S3
可視化
- Cloud Watch
分析とレポート
- QuickSight
アラート
- CloudWatch Events SNS
- lambdaによるSlack通知
監視を知るには
まとめ
- サーバレスで監視システムを作れるとは驚きだった
- 自作で作れる技術の高さは凄いと感じた
- 入門監視の本を読んでいたが、このような観点で読んでいなかった
AWS環境のセキュリティ運用(設計)をはじめてみよう
利用されるべきもの
Cloud Trail
- 操作ログ、API操作のロギング
- 全リージョンでの有効を推奨
Config
- フルマネージドサービス。AWSリソースの構成や変更を可視化
GuardDuty
Shield
- マネージドなDDos保護サービス。無料でL3/L4レベルが保護
- advanceプランは、L7や大規模なDDosに対抗
設計の基本
- マルチAZで冗長化
- AutoScalingGroupに入れる(インスタンスを簡単に増やせる)
- ELB・Nat Gateway を駆使してEC2はプライベートサブネットにすることで、セキュリティ面が向上。パブリックサブネットにEC2を置くことは極力避ける
- CloudFrontで静的コンテンツをキャッシュする場合、EC2ではなくS3にすることで、ミドルウェアがなくなり脆弱性管理が楽になる
- WAFを使う
IAMの管理
- IAMユーザーはMFA必須
- IAMユーザーは最低限のみ
- 複数アカウントをまたがる場合、スイッチロールを使う
System Manager (コンポーネント:Automation)のパッチ適用
- AutoScalingで1台ずつ自動的にパッチを当てる
ELBを入れるメリット
まとめ
- GuardDutyは知らなかったサービスでした
- 設計の基本やIAM管理については知識の復習となった
- System Managerでパッチ適用の自動化ができるとは驚きでした
あらゆるデータを分析・可視化!明日から始められるSumo Logic
Amazon DocumentDB(with MongoDB Compatibility)入門
ハイブリッドクラウド構成ガイド〜 2019年の今ならこう作る
VPCのベストプラクティス
VPC Sharing(Shared VPC)とResource Access Manager(RAM)
- AWS Organizarions必須
- 自由度が低く
- スケールしない
- テナントの通信(テナント間及びインターネット)を制御したい
- 制限事項がある(共有されたサブネットに作成できないリソースがある)
- シングルテナント、単一リージョンでは最初に候補に入れる
PrivateLink
- 1 vs Nの関係
- スケーラブル
- IPアドレス重複でもOK
- NLB使用
- アプリケーションの共有
Transit Gateway
- 1 vs 1でも1 vs Nでもルーティングテーブル次第
- スケーラブル
- ネットワークの共有
- 設計が難しい
まとめ
- VPC SharingとResource Access Manager:注意点として、新規でAWS Organizarionsを利用するのは簡単。逆に既存からだと少し考えてやる必要があるので注意が必要らしい
- Transit Gateway:便利そうな機能だが、極力はラストリゾートとして使用
- まずはVPC Sharing → PrivateLink →Transit Gatewayの順で検討すること
オンプレと密に連携が必要な Wi-Fiシステムを クラウドに移行するのは大変だった話
なぜクラウドへ
オンプレ時代
- 品質とスピードの向上
- ハードウェア管理からの脱却(インフラ環境構築まで2~3ヶ月、夜間リリース中心、レガシーな作業手順)
現在(クラウド)
- 品質とスピード(数時間で、複数インスタンの構築が可能)
- ハードウェア管理(サーバレス、インスタンスタイプ、リリース方法の刷新)
新しい構成で意識したこと
創業から10年で4,000名規模となったオンプレ製品の会社における、クラウド活用とビジネスの変化
登壇者は、ヤギを飼っていた!
休日の私に似た生き物。 pic.twitter.com/tfsY9B1ZWx
— Satoshi SHIMAZAKI🐐 (@smzksts) 2019年3月2日
AWSと似ているというお話し
見比べて見て。
【大河原克行のクローズアップ!エンタープライズ】HCIはひとつのステップにすぎない――、Nutanixが目指すエンタープライズクラウド戦略 - クラウド Watch
製品紹介
Xi Epoch:マルチクラウドにおけるアプリケーションの観察と監視
Xi Beam:クラウド環境全体をワンクリックのコスト最適化機能とともに、クラウド消費パターンの詳細な可視性と豊富な分析機能を提供。
Xi Frame:ブラウザ上で完全なデスクトップやアプリケーションを実行
セッション Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理するツール
Infrastructure as Codeとは
- 自動化、バージョン管理、テスト、継続的インテグレーション、継続的デプロイといった、ソフトウェア開発のプラクティスをシステム管理に応用するための方法論
- 工数削減、作業履歴、テスト自動化、オペミス削減、レビュー・フローのメリット
大事なこと
-
なんでもかんでもコード化するのはやめる
-
過度にコードをキレイにし過ぎない
- ROIを考えて手作業も視野に(コスト、スピード、リスクを評価する)
手作業ではダメなのか。何がダメなのか
- オペミスがある(オペミスしてもOKなところ、NGなところを分けてる?)
- 記録が残らない(作業内容、履歴管理、今の状態をエクスポートしたい)
- 再現性がない(本当に再現する必要ある?)
- 使い回せない(逆に今の状態をエクスポートしてインポートしたい)
- レビューができない(作業内容、変更するパラメータを事前レビュー)
働くことや学ぶことを見つめ直してみませんか?presented by クラウド女子会