kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Amazon CloudFront おぼえがき

AWS ソリューションアーキテクト プロフェッショナル

AWS 認定ソリューションアーキテクト – プロフェッショナル 対策

Amazon CloudFront って何?

Amazon CloudFront は、データ、動画、アプリケーション、および API を、低レイテンシーの高速転送により視聴者に安全に配信する、グローバルコンテンツ配信ネットワーク (CDN) サービスです。

https://aws.amazon.com/jp/cloudfront/

特徴

  • 元サーバに負荷をかけずに、サイトの高速化とスケーラビリティを簡単に実現可能
  • 動的コンテンツにも対応

用語

オリジン

元ネタのコンテンツがあるサーバ

  • インターネット経由でアクセスできることが必須

エッジサーバ

コンテンツをキャッシュ & 配信するサーバ。

  • CloudFront DNSが位置情報を元にユーザを最も近いエッジサーバに誘導する

CloudFront Distribution

  • CloudFrontの各設定のひとまとまりをDistributionという
  • Distributionには、 *.cloudfront.net のようなドメインが与えられる
  • web Distributionと、RTMP Distribution がある
    • 通常は web Distribution を使う
    • 以前は「ダウンロード」と「ストリーミング」という名称だった

RTMP

Real Time Messaging Protocol

Adobe Flash プレーヤーとサーバーの間で、音声・動画・データをやりとりするストリーミングのプロトコル。(らしい

いろいろな機能

キャッシュコントロール

  • 単一ファイルサイズのキャッシュは 最大20GB まで
  • URL/リクエスト(GET,HEAD,OPTION)/フォワードオプションの 完全一致 でキャッシュが利用される
    • フォワードオプションは、ヘッダ、Cookieの値、クエリストリングを参照できる
  • キャッシュを無効化するPathを指定できる(最大3000)
  • ワイルドカード指定も可能(最大15個

ダイナミックキャッシング

Behavior Cache TTL(正規表現)を設定することで、path毎にどのオリジンにアクセスするか設定できる

  • 静的コンテンツはS3、動的コンテンツはサーバを参照みたいな使い方を想定

AWS Lambda@Edge

エッジロケーション上でLambdaを実行できる仕組み(すごい!!

使いみち

  • 動的なレスポンス
  • ログ出力
  • アクセスコントロールなど

Price Class

設定すると安価なエッジロケーションのみ使用するようになる

  • 当然その分遅くなる

その他の機能

  • AWS ShieldによるDDos対策(無料
  • エッジ側でコンテンツをGzip圧縮できる

具体的な使い方

プライベートコンテンツの配信

ストリーミング動画配信

  • AWS Elemental MediaConvert でHLSなどのストリーミングプロトコルの動画に変換して、それを配信する
    • 変換結果はS3にupされる
  • HLSのマニフェストで、CloudFront Distributionを指定
    • HLSはマニフェストファイル(m3u8)と、動画ファイルに分かれている

ライブストリーミング動画配信

EBSスナップショットおぼえがき

AWS EBS

EBSスナップショットの料金について

0.05USD 1 か月に格納されたデータ 1 GB あたり

差分が保存されるため、複数回スナップショットを取った場合、2回目以降は差分のサイズだけの料金になる

Amazon EBS では空のブロックが保存されないため、スナップショットのサイズはボリュームサイズよりもかなり少なくなるはずです。 ボリュームの最初のスナップショットについては、データ全体のコピーが Amazon S3 に保存されます。 増分スナップショットごとに、Amazon EBS ボリュームの変更部分のみが保存されます。

料金 - Amazon Elastic Block Store（ブロックストレージ）｜AWS

EBSスナップショットとAMIの違い

AMI = 「EBS ボリュームの中のデータ(スナップショット) とインスタンスを構成する管理情報」を含む起動テンプレート

EBSスナップショットの取得を自動化したい

Amazon Data Lifecycle Manager (Amazon DLM) を使用して、Amazon EBS ボリュームをバックアップするスナップショットの作成、保持、削除を自動化できます

docs.aws.amazon.com

マイクロサービスおぼえがき

マイクロサービスについて知っておいたほうが Kubernetes 登場の背景を知れそうな気がしてきたのでメモ

成長したシステムを大きなチームで運用するのは大変

いろんな課題がある

チームが大きいと...

  • コミュニケーションコストが高い
  • 意思決定コストが高い

システムが大きいと...

  • 変更コストが高い
    • 影響範囲が見えづらい
    • 「歴史的経緯」が増えて学習コストが上がる
  • テストやビルドに時間がかかる
  • 最初に決定した言語、フレームワークに不向きな機能が
  • インフラリソースを一部のリソースを食う機能のために合わせなければならない

そこでマイクロサービス化ですよ

チームとサービスを分割して効率化させる

チームが小さいと...

  • コミュニケーションコストdown
  • 意思決定コストdown

システムが適切に分割されていると...

  • 各サービスの変更速度up
    • 歴史的経緯の消滅 & 影響範囲が限定的
    • 機能に最適化された、言語やフレームワークの選択
  • テスト/ビルド時間の低下
  • インフラリソースの効率化
    • 各サービス毎に必要な部分だけスケールできる

ということは、最初からマイクロサービスじゃなくてよいの?

そう。

1つのチームが複数のサービスを管理するのはむしろ効率が悪い

それに、ある程度サービスが使われないと、分割の勘所も分からない

マイクロサービスにする際に気をつけることは

各チームに責任・権限をしっかり分担すること

  • コミュニケーション&意思決定速度を上げるため

データもサービス毎に分割すること

ここをしっかり分けないと、マイクロサービス化する意味は薄い

大前提としてサービスをまたぐトランザクションが発生しないようにサービスを分割すべき 今回のように同一トランザクションでデータ更新をしたい処理であれば、サービス同士が疎結合ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い

各サービスが落ちていても動くように疎結合に設計すること

可用性が高くなる

でも、レコメンデーションエンジンの部分が独立して動いていれば、UI部分でレコメンデーションエンジンサービスの故障を検知したら、お薦めリストを表示しないというのもできるし、お薦めのデフォルトを呼び出すような事も可能になる。 こういう依存先サービスの故障を切り離すような機能をサーキットブレーカーと呼ぶ

ある程度の実装の重複は許容すること

下手に共有ライブラリとか作ると、その部分の変更コストが上がる

Cacoo の場合は gRPC サービスや RabbitMQ に関連する処理などがその典型です。これは microservices の特性上、許容すべきことです。共通の処理をライブラリ化してしまうという手もありますが、そうすると複数のサービスが同一のコードに依存してしまうため、microservices のメリットが減ってしまうことになります。

CacooはなぜKubernetesによるmicroservicesへの道を選んだのか？ | ヌーラボ

マイクロサービスの欠点はあるの?

いくつかある。

  • サービス間通信が複雑化する
  • 各サービスが独自のデータベースを持つのでサービス間でデータの一貫性がなくなる
  • アプリケーション全体の可用性が高まるとは限らない(１つのサービスの挙動が悪くなると全体に影響するケースもある
  • 統合テストが大変になる

ASCII.jp：マイクロサービスの境界を決める「DDD」とは？ (1/2)

あと、複数サービスが通信する関係上、モノリシックなサービスよりレスポンスは遅くなる

適切にサービスを分割するにはどうしたら良いの

ここが一番マイクロサービス化で難しいところらしい

DDDの「境界づけられたコンテキスト」単位で分けるのが適切らしいです(あんまりわかっていない

DDD本やマイクロサービスアーキテクチャを読むと理解できるのかも...?

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

マイクロサービスを動作させるのに適切な方法は何?

各サービスの機能をコンテナ化して、サービス毎のコンテナの集まりを管理するのがモダンらしい

これを実践するのに生まれたのが Kubernetes であるという認識

感想

  • マイクロサービス化は、ハイコストハイリターンの「究極的な技術的負債の返済」だと感じた
  • 当たり前だけれど「銀の弾丸」ではない
  • サービス起動時から予め「このくらいの規模になったらマイクロサービス化を実施する」というのを経営陣と共有しておかないと難しそう

次回

マイクロサービスを理解したところで、それを実際に動作させるプラットフォームとしての Kubernetes を理解する

古いCentOSのcurlで、githubにアクセスしたい時に見るページ

Linux 
curl --tlsv1.2 https://github.com/hoge.keys

--tlsv* オプションで、通信に使用するTSL/SSLのバージョンを指定できる

  • TLS 1.0 は脆弱性があるため、無効になっているサイトが多い(githubとか)
  • しかし、古いバージョンのcurlにはバグがあり、TLS 1.0 でしかアクセスできないらしい
  • --tlsv1.2 など、オプションで TSL のバージョンを明示することで、TLS 1.0 以外も使用可能

参考: 世の中にはTLS v1.0も許可しない業界があるようで — サイバートラスト株式会社

ハードリンクしたファイルはinode番号が同一値になる

Linux

inode とは

UNIX系ファイルシステムで使われているデータ構造

  • UNIXのファイルは、inodeと、実際のデータの組み合わせ
  • inodeには、inode番号と、ファイルのサイズなどの属性情報が格納されている

inode番号 とは

各nodeに与えられる任意の値

  • 各ディレクトリは、node へリンクを貼ることでファイルを管理している
  • node番号は ls -i で確認可能

ハードリンクを生成すると、どちらも同一のファイルを参照するため、node番号は同一値となる

例

$ ls -li aaa bbb
8610608681 -rw-rw-rw-  2 kasei_san  staff  221  8  2 11:28 aaa
8610608681 -rw-rw-rw-  2 kasei_san  staff  221  8  2 11:28 bbb

ls の -i オプションで、inode番号が確認できる

rm まめちしき

  • rm コマンドはファイルの削除ではない。ディレクトリから対象のnodeを外すだけ
    • unlink というコマンドもある(カーネルによっては rm のハードリンク)
  • 一つもリンクが無く、openされていないnodeは、その後削除される

EC2のリザーブドインスタンス。同一 Region 単位で取得できる最大数は20まで

AWS EC2

f:id:kasei_san:20180908153036p:plain

Region 単位, Availability Zone 単位 それぞれでリザーブドインスタンスは最大20台まで

リザーブドインスタンスは Region 単位 と、availability zone単位 がある

  • Region 単位 : どの AZ で動かしてもよいが、AZ にインスタンスの空きがない場合、起動できない
  • Availability Zone 単位 : AZ の移動はできないが、予約したインスタンスはかならず確保できる

20台以上必要な場合は、サポートを通じて制限を増やして貰う必要がある

(自分が問い合わせたときには、本社に問い合わせる必要があるので2-3日かかると回答された)