AWS神回

もともとはAWSをAPIを使用のみのサービスだったのでこのときはまだコンソールはありません。2008年にはCloudFront,EBSが稼働しました。2009年からAutoScaling,CloudWatch,AWSのコンソールが稼働しました。ようやく現在でもメインとなっているコンソールがこの年に登場しました。2014年にはECS,Lamdaが稼働、 … 続きを読む

Sophos CentralでIAM Roleを利用したAWSアカウント連携してみた

こんにちは、臼田です。 Sophos CentralはAWS上で利用しやすいアンチマルウェア製品のSophos Server Protectionをクラウド上で管理できるツールです。Sophos CentralとAWSアカウントを連携することにより、AutoScalingで増減した管理対象のEC2を自動的に登録/削除することができる事も魅力の1つです。 以前までは … 続きを読む

1ヶ月でAWS 認定ソリューションアーキテクトに合格した話

昨年(2017年)の8月にAWS 認定ソリューションアーキテクト – アソシエイトに合格しました。
ほぼゼロからの勉強でしたが、要点を抑えれば短期間でも合格できたので、やったことを紹介します。

1. 前提知識

趣味で触ったことがあるもの。※どれも軽く触った程度

  • EC2
  • ELB
  • S3
  • Lambda (試験には出ない)
  • API Gateway (試験には出ない)

2. 対策内容

2-1. AWS Summit Tokyo 2017 セッション資料・動画

オススメ度: ★★★★★

一番オススメです。
「試験範囲の動画を見る → 実際にAWS上でやってみる」で大体雰囲気つかめました。
各サービスの「入門」だけで十分だと思います。
(話すペースがゆっくりなので、1.5倍速ぐらいで見ないと眠くなります。)

2-2. AWS Black Belt

オススメ度: ★★★★☆

安定の公式資料集です。
そこそこボリュームあるので、自分は理解の浅いサービスに絞って読みました。
(試験範囲の資料は一通り目を通した方が良いのかも?)

2-3. 参考書

オススメ度: ★★★☆☆

唯一の対策本なので、読んでおいて損はないと思います。
ただ情報量は少なめなので、概要をつかむ程度に使いました。

オススメ度: ★★☆☆☆

ハンズオン形式で進めるので、イメージがつきやすいです。
ただこちらも情報量としては足りてないので、合わせて他の対策も必要です。

2-4. AWS WEB問題集

オススメ度: ★★★☆☆

無料枠のみ解きました。
本番と似たような問題が出題されるので、そこそこ参考になります。
(何問かは本番とまったく同じ問題でした。運が良かっただけかも?)

3-5. それっぽい構成で作ってみる

オススメ度: ★★★★☆

ある程度理解が進んだら、サービスを複数組み合わせて何か作ってみるのがオススメです。
自分の場合は以下の構成で、Hello Worldをブラウザから表示するぐらいの簡単なものを作りました。

 VPC + ELB + EC2 + AutoScaling + CloudWatch + Route53

3. 結果

正答率(模擬試験): 75%
正答率(実試験): 72%

試験当日は、そこそこ感触が良かったのですが、思ったより点数が伸びず^^;
何はともあれ、一発合格できて一安心でした。

4. 感想

  • 実際に手を動かすことが一番タメになりました。やってみないとわからないことがけっこうあります。
  • ある程度知識が付いた段階で、模擬試験を受けることがオススメです。雰囲気つかめます。
  • セキュリティグループとネットワークACLに関する問題が多く出題された気がします。
  • とにかく試験会場が暑かった。。。

続きを読む

AWS DDoS対策勉強まとめ

・DDOS攻撃
複数の攻撃元が協調して大量のパケットやリクエストを送ってサービスを停止させる

・ランサムDDoS
攻撃者が公開サーバーをいつでも停止できる

下記三軸で考える
【高さ】
レイヤーごと
– アプリケーション層攻撃
アプリケーションリソースを攻撃。
HTTPGET

DNSクエリフロッド
→ボットネットと呼ばれる複数の感染ホストを利用し、大量のクエリをDNSに配信

  • 状態枯渇攻撃
    ファイヤーウォールなどに攻撃
    TCP SYNフロッド
    →クライアントから意図的にACKを返さないことで、他のユーザがアクセス出来なくする
  • ボリューム攻撃
    処理できる能力を越えたトラフィックを送る
    UDP反射攻撃
    →攻撃者はIPを偽装。要求と応答のパケットのサイズ差を利用

【深さ】
アプリケーションごとに対策は違う。
→エッジとリージョンなど

・ウェブアプリケーションの場合
エッジでAWS WAF, CloudFrontを利用
リージョンでセキュリティグループで対策

・クライアント/サーバーアプリケーションの場合
EC2の垂直スケール、拡張ネットワークでトラフィック吸収

・ゲームアプリケーションの場合
Routing Matching ServiceでIP配布
特定のIPのみからアクセスするよう制御

【幅】
・地理的分散
→CloudFrontで配信分散

・攻撃対象隠蔽
→セキュリティグループ使用
→Amazon API Gatewayを利用。Web API公開サーバーを立てない
→ELBでEC2を見せない

・攻撃吸収、緩和
→AWS Shieldによる自動緩和システム
→CloudFrontによるGEOリストリクション
→Route53。高可用性
→ELBとAutoscalingでインスタンスそp増減
→拡張ネットワーク。NICへのアクセスを複数あるようにする

・計画、監視
→CloudWatchでの監視

・AWS Shield Standard
Layer 3/4 protection
→一般的な攻撃から防御
無料

Layer 7 protection
→WAFを利用
→使った分だけ支払い

・AWS Shield Advanced
Standardに加え、より大規模な攻撃からの防御

参考URL:
https://www.slideshare.net/mobile/AmazonWebServicesJapan/20170905-aws-blackbeltddosmitigation-79478348

続きを読む

オートヒーリングでゆるーくEIPもヒーリングしてみた

こんにちは、臼田です。 今回はAutoScalingを利用したインスタンスの自動復旧(オートヒーリング)時にEIPもヒーリングする方法を考えたのでご紹介します。 目的 例えば下記のようにWebサーバの環境で、低コストに抑 […] 続きを読む

【新機能】AutoScalingの新ダッシュボードが発表されました!

ご機嫌いかがでしょうか、豊崎です。 AWSマネジメントコンソールに、新しくAutoScalingのダッシュボードができましたのでご紹介したいと思います。 New AWS Auto Scaling – Unified Scaling For Your Cloud Applications. 専用ダッシュボードを利用することで、CloudFormation、または AWS Elastic Beanstalk で構築され … 続きを読む

「Microservices Meetup vol.6」に行ってきた

2017/1/19のデイリーストックランキングにランクインしました。

【毎日自動更新】Qiitaのデイリーストックランキング!ウィークリーもあるよ_-_Qiita.png


いままでの。
「Microservices Meetup vol.2」行ってきたメモ。
「Microservices Meetup vol.4」に行ってきた

図らずして1回おきに参加してますね。

Connpassのイベントページ

少し間が空いてしまったがまた定期的に開催していきたいです。
登壇したいよーって人は直接リプ投げてください
by @qsona さん

Microservices on AWS by @Keisuke69 さん

Keisuke Nishitani @ AWS

Specialist Solutions Architect

サーバーレスアプリケーション開発ガイド 2月発売

マイクロサービスのポイント

  • 管理運用まで含めて分散型
  • 各コンポーネントが独立している
    • 単独で実行できないのは適切に設計されていない

独立して分散していると負荷の高い機能の単位でスケールさせられる=コスト効率が良い

  • 一つのことをうまくやる

    • 複雑化したら分割する
  • 多言語

    • チーム(機能)にはそれぞれの問題に対して適切なツールを選択する自由がある
    • OS、言語、各種ツールに至るまで最適なアプローチを目指せる
  • 検索:Elasticsearch / Solr

  • ソーシャル:グラフDB

  • ログデータ:Cassandra

  • セッション:Redis

†AWSでは:AWSには100ちょいのサービスがあって、その中で更にチームが分かれている。
各チームに社内標準の開発プロセスは存在しない。

  • ブラックボックス

    • 詳細は外部のコンポーネントに公開されない
  • DevOps
    • マイクロサービスにおける組織原理

†AWSでは:運用のみのチームはない。オンコールも開発チームが請け負う

  • 俊敏性

    • 狭い範囲のコンテキストで活動=サイクルタイムが短い
    • システムもシンプル
    • パラレルな開発とデプロイが可能
  • イノベーション

    • 選択に対する権限と責任を持つのでイノベーションを起こしやすい
    • DevとOpsの対立がないため、効率化やイノベーションが起こしやすい
  • 拡張性

    • 適切に非干渉化されてていることで水平方向に単独にスケールできる
  • 可用性

    • ヘルスチェック、キャッシング、隔壁、サーキットブレーカーと言った仕組みは全体の可用性を向上させる

課題

  • 分散型であることは難しい

    • システム数が増える
    • 協調動作の難しさ
    • コンポーネント間のコミュニケーションメッセージ増によるレイテンシ低下
    • ネットワークの信頼性は無限ではない、帯域も無限ではない
  • 移行が大変
    • モノリシックなシステムの分割は難しい
  • 組織
    • 組織体制の変更が必要になるが、それは大変なこと
  • アーキテクチャの難易度
    • 非同期通信
    • データ整合性
    • やっぱりココが一番の課題
    • サービスディスカバリ
    • 認証
  • 運用の複雑さ

アーキテクチャ

一番シンプルなパターン

CloudFront – ALB – ECS – datastore(ElastiCache, Dynamo, )
|
S3

  • バックエンドをRESTfulなAPIにしたSPA
  • 静的なコンテンツはS3とCloudFront
    • CDN通すことでレイテンシが上がることもある
    • キャッシュとの併用を検討
  • ECSとAutoScalingをALBとともに使うことが多い
    • ALB(L7LB)でアプリレベルの情報をルーティング
    • コンテナインスタンスにリクエストを分散
    • ECSのコンテナを負荷に応じてスケールアウト/インする

コンテナのメリット

  • Portable
  • Flexible
  • Fast
    • 軽量で早い
    • ポータビリティと関連して開発サイクルも早く
  • Efficient

  • 一貫性のある環境

  • バージョン管理出来る

Dockerの特徴

  • Package
  • Ship
  • Run

ECS

  • 複数のコンテナをEC2のクラスタ上で一元管理

    • まだTokyoにきてないけど、FargateでEC2の管理もいらなくなるよ
    • EKS(Kubernetes)も発表されています

データストア

  • インメモリ

    • Memcached, Redis
    • ElastiCache
    • DB負荷の軽減
  • RDBMS
    • 無限のスケーリングには向いていない
    • Amazon RDS
  • NoSQL
    • 水平スケーリングをサポートするものが多い
    • テーブル結合ができないのでロジックの実装が必要になる場合も
    • Amazon DynamoDb, KynamoDB Accelarator(DAX)

APIの実装

  • APIの設計、改善、デプロイ、モニタリング、保守派手間がかかる
  • 異なるバージョンが混在すると大変

Amazon API Gateway

  • 複数バージョンとステージ
  • Cognite User Poolsと連携して認証を追加
  • スロットリング、モニタリング
  • バックエンドとしてLamdbaが使える

サーバーレス

  • サーバーはないに越したことはない
  • スケーリングと高可用性の担保が大変
CloudFront - API Gateway - Lamdba - datastore
   |                            (ElastiCache, Dynamo)
   |
  S3

課題をAWSでどうするか

サービスディスカバリ

  • お互いの死活確認や発見
  • ハードコードするとスケールできない

    • メタデータをどこに置くか
  • ALBを利用したサービスディスカバリ

  • DNS(Route53)のサービスディスカバリ

    • VPC単位の振り分け
  • ECSイベントストリームを使用したサービスディスカバリ

    • CloudWatchイベントで拾ってキック
    • LamdbaでRoute53に登録
    • これが一番多いかも
  • DynamoDBを使用したサービスディスカバリ

    • DNSキャッシュの問題がない
    • 自由度が高い
    • 実装が大変
    • DynamoDBストリームを活用して他のサービスへステータス変更を反映
  • イベントベースのアーキテクチャ

    • イベントで処理する
    • いわゆる結果整合性とも関連
    • Dual Write Problem
    • Event Sourcing
      • 状態の記録ではなく状態の変更「イベント」を記録
      • Amazon Kinesis
      • kinesisにpublishして他サービスはsubscribe
      • S3にログを残す
      • トランザクションログの仕組み

モニタリング

  • CloudWatch

    • ログファイルの一元化
    • CloudWatch LogsかS3に保存可能
    • ECSはCloudWatch Logsに一元化できる

分散トレース

  • AWS X-Ray
  • 複数サービスに分散したリクエスト処理を透過的に追える

LogWatchの先に Kinesis FireHorse – ほにゃほにゃ

スロットリング

  • 大事だよ

リトライ

  • 多くのエラーはリトライでカバーできるものが多い
  • リトライ多発で過負荷になることがある
    • Exponential back offもしくはフィボナッチ数列を利用したリトライ感覚の調整
    • 更に乱数でゆらぎを付けて重ならないように

LT:クラウド型医療系業務システムと Microservices への歩み by @hashedhyphen さん

https://speakerdeck.com/hashedhyphen/kuraudoxing-dian-zi-karutesisutemuto-microservices-hefalsebu-mi

クラウド型電子カルテシステムの話

  • メインロジックをRails
  • 常時接続をNode.js
  • バックエンドをScala
  • 基盤はAWS

ここに至る道のり

ファーストリリース前

  • レコメンドは大量のデータが必要

  • メインロジックで実現させようとすると厳しかった

    • Threadとか試したけど……
    • 別アプリケーションとして分離
    • JVM上でScala + Skinnyでスレッドアプリケーションンを実装
    • Microservicesちっくな構成へ
  • 障害検知時

    • メインロジック内のプロトタイプ版が動く!

会計機能リリース前

  • お金を扱う機能は安定性が欲しい
  • Scala + Cats による実装を別エンドポイントとして実装
  • マイクロサービスっぽい作りになっていたから自由度のある技術選択が出来た

まとめ

  • ちょっとマイクロサービス化したことで自由度が上がった
  • 原理主義的にならなくても恩恵がある
  • エンジニアの伸びしろ!

FrontEndからみるmicroserviceとBackendからみるmicroservice by @taka_ft さん

Takahiro Fujii @ Rakuten Travel

楽天内でも採用アーキテクチャはサービスによって異なる。

サービスとしては

  • コンシューマ向け
  • Extranet
  • In-house
  • other
    • ここまではWEBとモバイルがあって、100以上のAPIを利用する
  • API(内部APIを直接利用)

Phase 1

  • 大きなモノリシックなアプリだった
  • 機能がどんどん増えていく
    • 機能別で複数のモノリシックなアプリに分割
    • その後フロントエンドとバックエンドに分割

Phase 2

  • ドメインモデルを整理
  • なるべくRESTfulで作るようになっていった
  • 大きなAPIから小さなAPIに分離
  • I/Fの決定に時間がかかるようになった
  • API呼び出しが大変になった
  • Microservicesっぽくなってきた 2014年くらい

  • 国内予約、海外予約で多言語化だけではない商習慣に根ざしたドメインの差異による重複ロジックの増殖が起きた

  • Microservicesっぽくなってきたが、どんどん品質が下がっていった

Phase 3

(ちょうど前日にプレスリリース)サイト前面刷新に向けての取り組み

  • FrontendsはJavaScriptに刷新
  • API GatewayにKong

組織

  • フロントエンドチームが2人から始まって半年でReactエンジニアを集めて20人以上に

    • 日本人は2, 3人

UI Component

  • SpringからJavaScriptでSPAに変更
  • zeplinのデザインモックからUI Componentを実装するようになった
  • Storyboardを使ってUI Coponentを管理
  • ドメインを含むUI Componentはドメインと結び付きが強いことが多い=専用のオーケストレーションAPIを用意してUI Componentないで処理を閉じることが出来る
  • レスポンシビリティを明示的に定義

    • どこまでフロントエンドでやるか、どこからAPIからもらうか
  • フロントエンドの「使いやすいレスポンス」の要求

  • バックエンドの「汎用的でシンプルなレスポンス」の希望

    • これらのバランスを取る
  • API Gatewayはフロントエンド(UI)チームの管轄

    • ただし状況によってはバックエンド側に持っていくことも検討するつもり

LT: “マイクロサービスはもう十分”か? by @qsona さん

https://speakerdeck.com/qsona/enough-with-the-microservices

POSTDに投稿していた翻訳記事。

スタートアップ企業のほとんどはマイクロサービスをさいようすべきではない

銀の弾丸はない。

「チーム間の依存性」の解決にマイクロサービスというアプローチは違う。疎結合と分散は別。

組織が大きくなると、複数チームが1つのコードベースを触るようになる。そしてマイクロサービス化したくなる。

しかし、モノリスの分割で十分。

チームとは何か

  • 自律的に動けるべき

    • チームが増えるとコミュニケーションコストや、しがらみ
  • チームの分割は目的にそった分割を行う

  • 悪い分割の例: Dev / Ops

  • 依存度が低いほど自律的に動ける

  • High Output という本

  • 使命型組織/技術型組織

    • Micorservicesは使命型組織
    • 組織間が密ならサービス間も密になる

話戻して

  • スタートアップは組織をキレイに分割することが難しい
  • 分割しても密になってしまう

  • 大きなモノリスになるとやはり分割は難しい

    • ドメインの意識は必要
  • マイクロサービス設計しなくても「マイクロサービス精神」で開発すると効果的なのではないか

FiNCが初期からマイクロサービスでやってた理由

  • 単独の事業にできるような一つ一つのサービスを組み合わせて提供してきたから

あとで読み返して修正します。
資料パスの追加とかも。

続きを読む

Dynamic DNS creation for core nodes in case of Autoscaling – AWS

パイソン & Linux Projects for $30 – $250. We wanted to implement the Dynamic creation/Deletion of DNS for nodes, when the AWS EMR cluster Autoscales up and down for Route53 using Autoscaling cloudwatch events that triggers a lambda function… 続きを読む

【2018年】AWS全サービスまとめ その2(開発者用ツール、管理ツール、メディアサービス) | Developers.IO

AWSのリソースおよびAWSで実行しているアプリケーションのモニタリングサービス。メトリクス(CPU使用率やネットワークI/Oなど)やログを収集し(CloudWatch Logs)、SNSやAutoScalingと連携するアラームを作成できる。またAWSリソースの変更イベントを監視し、Lambdaなどのターゲットに対して、リアルタイムに通知が … 続きを読む