AWS 定番業務システム14パターン設計ガイド(2章)

2章をまとめてみました。

キーワード

オンプレミス環境のデータをバックアップ

1)AWS CLIを利用してS3にバックアップ

  • オンプレミスのサーバからS3にはAPI接続
  • 転送料金はS3への受信は無償、送信は有料
  • バージョニング、ライフサイクル、暗号化

2)EC2を使ったDBバックアップ

  • AWS CLIでDBファイルをS3に転送
  • EC2上でDBMSでデータ同期
  • DRBDはEC2のEBSボリュームに同期

 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の参照先振り分け機能


4)ストレージI/O帯域の対策

  • EC2インスタンスのOP:EBS最適化
  • EBSボリュームのOP:プロビジョンドIOPS


5)Auto Scalingグループ作成

  • 予測可能や予測不可のスケーリングポリシー
  • EC2インスタンス購入オプションでコスト減


6)Auto ScalingグループでのAMI作成

  • デプロイ方法はアプリのリリース頻度で決定
  • インスタンス終了に備えデータをEBSへ退避


7)EC2インスタンスを自動復旧


8)DRに自動切替えするにあたって


まとめ

可用性、性能、CostがWebシステム設計の観点

すべての知識を「20字」にまとめる 紙1枚! 独学法

この本を読んで、まとめてみました。

 

www.amazon.co.jp

 

学んだことを忘れないために必要なのは

思考整理する上で大事なのは考え抜くこと。これにより本質をつかむ力が付く。本質は、シンプルで端的な言葉で表現すること。

  • 目的の明確化
  • 思考整理
  • 端的な要約

 

インプット

以下の項目に沿っていく。

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
  • 働き方

 

jawsdays2019.jaws-ug.jp

  

 サーバレスで動かすトークン発行プラットフォーム

 

ブロックチェーンとは

  • ブロックチェーンは、ビットコインなどの仮想通貨を実現する技術として登場した
  • 重要なデータをネットワーク上で共有しながら管理する技術
  • 従来の銀行システムと比べ、ブロックチェーンの強みは、中央集権化の防止、取引コストの削減、情報の改ざんが困難

www.sbbit.jp 

Ethereum(イーサリアム

  • イーサリアムとは Vitalik Buterin 氏によって開発された、プラットフォームの名称です
  • ブロックチェーン上に契約内容を記録し、期日になると自動で契約内容を実行してくれるシステムを実装できることです。このシステムをスマートコントラクトと呼びます
  • スマートコントラクトの機能を利用して、分散型アプリケーション(英: Decentralized Applications、略称: DApps)を構築することができます
  • DApps とは、企業や銀行などの中央管理者がいなくても稼働するアプリケーションのことです
  • DApps はアプリケーションを利用する参加者全員がデータを分散管理し、仕様変更などの意思決定に関わることができます

bitflyer.com

 

Slack(スラック)

  • スチュワート・バターフィールドによって開発された、チームコミュニケーションツール
  • UIとして使っている

 

SimplexToken(仮想通貨)を発行して社内で利用してもらう

最小限の機能

  • 残高照会

  自分はどのくらい仮想通貨を持っているか確認できる

  何かしらのトリガーで仮想通貨がもらえる

 

登場したAWSサービス

 

 トークン発行をベースとしたプレゼンサポートアプリの開発

今回導入したAWSサービス

 

まとめ

  • 初めてブロックチェーンの分野に触れてみた。用語や仕組み、この技術をどのように活用し何ができるのかを知らなかった。このセッションで、どんな活用方法があるかを知った。また、どんな技術かを調べるきっかけとなった
  • 前半の構成は、API Gateway + Lambda + DynamoDB を使った一般的なサーバレス。イーサリアムやスラックの動きはスライドで想像ができた
  • 後半の構成は、Vue.jsのSPAをS3にホスティングできることやCloudFormation(SAM)を使ってLambda, API Gateway,DynamoDB のリソースをひとまとめに管理 (作成 / 更新 / 削除) することができることは知らなかった

 

speakerdeck.com

 
AWS Serverlessを活用したサービス監視

なぜサーバレスで創るのか

  • 常時データを送信しても良いエンドポイントの提供
  • サーバを常時起動せずとも実行できるランタイム環境の提供
  • サーバ不要な管理レス、運用、費用面での大きなアドバンテージ

監視サービスのコンポーネント

データ収集

  • Agent:サーバーの状態を監視する
  • Monitoring:サービスの提供状況を監視する
  • Error:サービスのエラー状況を監視する

 

データストレージ

  • Cloud Watch
  • DynamoDB
  • S3

 

可視化

 

分析とレポート

  • QuickSight

 

アラート

  • CloudWatch Events SNS
  • lambdaによるSlack通知

 

監視を知るには

www.oreilly.co.jp

まとめ

  • サーバレスで監視システムを作れるとは驚きだった
  • 自作で作れる技術の高さは凄いと感じた
  • 入門監視の本を読んでいたが、このような観点で読んでいなかった

 

slide.seike460.com


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でパッチ適用の自動化ができるとは驚きでした

 

speakerdeck.com



あらゆるデータを分析・可視化!明日から始められるSumo Logic

dev.classmethod.jp

 
Amazon DocumentDB(with MongoDB Compatibility)入門

www.slideshare.net

 
ハイブリッドクラウド構成ガイド〜 2019年の今ならこう作る

VPCのベストプラクティス

  • 小さいVPCは、各サービスごとにVPCを作りそれぞれで管理。サービス開発で利用される
  • 大きい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の順で検討すること

 

www.slideshare.net

 


オンプレと密に連携が必要な Wi-Fiシステムを クラウドに移行するのは大変だった話

なぜクラウド

オンプレ時代

  • 品質とスピードの向上
  • ハードウェア管理からの脱却(インフラ環境構築まで2~3ヶ月、夜間リリース中心、レガシーな作業手順)

 

現在(クラウド

  • 品質とスピード(数時間で、複数インスタンの構築が可能)
  • ハードウェア管理(サーバレス、インスタンスタイプ、リリース方法の刷新)

 

https://image.slidesharecdn.com/jaws-2019-190301004943/95/jaws-days-2019-wifi-28-638.jpg?cb=1551402280

 新しい構成で意識したこと

 

https://image.slidesharecdn.com/jaws-2019-190301004943/95/jaws-days-2019-wifi-30-638.jpg?cb=1551402280

 

www.slideshare.net


創業から10年で4,000名規模となったオンプレ製品の会社における、クラウド活用とビジネスの変化

登壇者は、ヤギを飼っていた!

 

AWSと似ているというお話し

見比べて見て。

https://cloud.watch.impress.co.jp/img/clw/docs/1068/118/07.jpg

【大河原克行のクローズアップ!エンタープライズ】HCIはひとつのステップにすぎない――、Nutanixが目指すエンタープライズクラウド戦略 - クラウド Watch

 

製品紹介

Xi Epoch:マルチクラウドにおけるアプリケーションの観察と監視

www.nutanix.jp


Xi Beam:クラウド環境全体をワンクリックのコスト最適化機能とともに、クラウド消費パターンの詳細な可視性と豊富な分析機能を提供。

www.nutanix.jp

 

Xi Frame:ブラウザ上で完全なデスクトップやアプリケーションを実行

www.nutanix.jp

 

 


セッション Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理するツール

Infrastructure as Codeとは

  • 自動化、バージョン管理、テスト、継続的インテグレーション、継続的デプロイといった、ソフトウェア開発のプラクティスをシステム管理に応用するための方法論
  • 工数削減、作業履歴、テスト自動化、オペミス削減、レビュー・フローのメリット

 

大事なこと

  • なんでもかんでもコード化するのはやめる

  • 過度にコードをキレイにし過ぎない

  • ROIを考えて手作業も視野に(コスト、スピード、リスクを評価する)

 

手作業ではダメなのか。何がダメなのか

  • オペミスがある(オペミスしてもOKなところ、NGなところを分けてる?)
  • 記録が残らない(作業内容、履歴管理、今の状態をエクスポートしたい)
  • 再現性がない(本当に再現する必要ある?)
  • 使い回せない(逆に今の状態をエクスポートしてインポートしたい)
  • レビューができない(作業内容、変更するパラメータを事前レビュー)

 

 

speakerdeck.com


働くことや学ぶことを見つめ直してみませんか?presented by クラウド女子会

 

applebear.hatenablog.com

 

www.slideshare.net

 

 

 

*1:SPAとは「Single Page Application」の略で、単一のページでコンテンツの切り替えを行うWeb アプリケーションのアーキテクチャの名称です

*2:SAM(AWS Serverless Application Model)とは、サーバーレスアプリケーションを構築するためのフレームワーク (モデル) です。Lambda, API Gateway, DynamoDB のリソースをひとまとめに管理 (作成 / 更新 / 削除) することができます。