今週勉強したことまとめ(2017/12/11 ~ 2017/12/17)

Docker

AWS

EC2

  • SpotInstance

    • AWSで使用されていないリソースを対象に、需要と供給にあわせて、価格が変動するインスタンス
    • 通常のインスタンスより安く購入できる
    • 価格は常に変動するため、希望する購入価格を超える場合には起動しているインスタンスが削除される
    • 価格はAWS上のすべてのサーバに対してではなく、Availability Zoneごと、インスタンスタイプごとにグループ分けされている
    • 同じプールからすべてのインスタンスを購入してしまうと、そのプールが他のプールに比べて価格が安ければ、最安値で購入できますが、高いときには総合的に高い
    • 最悪の場合、上限価格を超えてすべてのサーバが削除されてしまう

  • SpotFleet

  • AutoScaling

CloudFront

DynamoDB

  • key, itemなどは予約語なのでパラメータとして使用する場合は、以下のようにエイリアスを貼る必要がある
ExpressionAttributeNames: {
      "#k": "key",
      "#i": "item",
      "#is": "items"
}

ECS

  • ecs-deploy
    • How it works
      • EC2コンテナサービスでは、タスク定義には、便利なアプリケーション（データベース、Webフロントエンド、メンテナンス/ cronなど）を一緒に提供するコンテナのグループ間の関係が指定されています。
      • タスク定義は、そのグループ内のコンテナを実際に実行するための一種のテンプレートとして機能します。
      • コンテナの結果のグループは、タスクと呼ばれます
      • Dockerがネットワークを実装する方法のため、一般に、コンテナインスタンス（クラスタインフラストラクチャを提供する仮想マシン）ごとにタスク定義ごとに1つのタスクしか実行できません。
      • タスク定義は自動的にバージョン管理されます---タスク定義の実際の名前は、姓とバージョン番号の2つの部分で構成されます。
      • タスクは広範なアプリケーションの完全に自己完結型の「ワーカーユニット」であるはずなので、Amazonは別の構成エンティティであるサービスを使用して、いつでも実行されているタスクの数を管理します。
      • タスクは単にタスク定義のインスタンス化であるため、サービスはタスク定義の指定されたリビジョンとそこから実行すべきタスクの数との間のバインディングに過ぎません。
      • 好都合なことに、Amazonは、このバインディングを更新して、実行中のタスクの数を変更したり、作成されたタスク定義を変更したりすることができます。
      • 前者の場合、サービスは、数量を仕様に合わせるためにタスクを構築または終了することによって応答します。

      • ただし、後者の場合は、Blue/Greenデプロイメントを行います。つまり、以前のタスクを強制終了する前に、新しいタスクが起動され、使用準備ができていることを確認します。

      • したがって、新しいバージョンのアプリケーションを展開するために必要なのは、そのタスクを実行しているサービスを新しいバージョンのタスク定義を指すように更新することだけです。

      • ecs-deployはpython awsユーティリティを使ってこれを行います。
      • ecs-deployは
        • 使用中のタスク定義のJSON表現をプルします
        • それを編集します
        • 変更を加えた新しいバージョンを定義します
        • 新しいバージョンを使用するようにサービスを更新します
        • Amazon APIを照会して、サービスが新しいタスクを作成できることを確認します
      • 2番目のステップではより多くの説明が得られます。
        • タスク定義は複数のコンテナを定義する可能性があるため、新しいリビジョンを作成するためには何を変更する必要がありますか？
        • 経験的に、驚くべき答えは何もない。
        • Amazonでは、タスク定義の新しいバージョンと同じバージョンを作成することができますが、サービスでは依然として同じタスクの青緑の展開が行われます。
      • それにもかかわらず、システムはドッカーを使用するため、アプリケーションの改善がコンテナイメージに組み込まれ、リポジトリ（公開または非公開）にプッシュされ、ECSで使用するためにプルダウンされるという前提があります。
      • したがって、このスクリプトは指定されたイメージパラメータを変更キーとして使用して、コンテナのイメージで使用されるタグを変更します。
      • 指定されたパラメータと同じリポジトリ名を持つイメージを検索し、そのタグを指定されたパラメータのものに更新します。
      • この結果、タスク定義で同じイメージを使用するように複数のコンテナを定義すると、異なるタグを最初に使用するように設定しても、それらのすべてが指定されたタグに更新されます。しかし、これはまれなユースケースと考えられています。

Kubernetes

service mesh

  • 現実世界のマイクロサービス：サービスに陰りが見え始め、いよいよ本気になるとき

  • What’s a service mesh? And why do I need one?

    • サービスメッシュとはサービス間の通信を安全で速くそして信頼できるものにするための専用のインフラレイヤ
    • クラウドネイティブアプリケーションを構築しているならきっとサービスメッシュが必要でしょう
    • ここ数年、サービスメッシュはクラウドネイティブスタックに欠かせないコンポーネントとして現れた
    • PayPal, Lyft, Ticketmaster, そして Credit karmaのようなはいトラフィックな企業はプロダクションのアプリケーションにサービスメッシュを導入した
    • そして今年1月クラウドネイティブアプリケーションのためのOSSのサービスメッシュであるLinkerdはCloud Native Computing Foundationの公式ぷろじぇくとになった　
    • この記事では、サービスメッシュを定義し、ここ10年間のアプリケーションアーキテクチャの変遷を追います
    • サービスメッシュはAPIゲートウェイ、エッジプロキシ、およびエンタープライズサービスバスの関連しているが概念とは区別されます。
    • 最後に、サービスメッシュがどこに向かうのかを説明し、クラウドネイティブの採用とともに、このコンセプトがどのように進化するのかを説明します
    • WHAT IS A SERVICE MESH
      • サービス間の通信をハンドリングする専用のインフラレイヤ
      • これは、最新のクラウドネイティブアプリケーションを構成する複雑なサービストポロジを使用して、リクエストを確実に配信する役割を担います
      • 実際には、サービスメッシュは、通常アプリケーションを認識する必要がなく、アプリケーションコードと一緒に展開される軽量ネットワークプロキシの配列として実装されます。 （しかし、このアイディアにはさまざまなバリエーションがあります。）
      • 別の層としてのサービスメッシュの概念は、クラウドネイティブアプリケーションの登場に結びついています。
      • クラウドネイティブモデルでは、1つのアプリケーションが何百ものサービスで構成されている場合があります。
      • 各サービスには数千のインスタンスが存在する可能性があります。
      • これらの各インスタンスは、Kubernetesのようなオーケストレーターによって動的にスケジュールされるため、常に変化する状態にある可能性があります。
      • この世界のサービス通信は信じられないほど複雑なだけでなく、ランタイム動作の普及した基本的な部分です。
      • エンドツーエンドのパフォーマンスと信頼性を確保するには、それを管理することが不可欠です。
    • IS THE SERVICE MESH A NETWORKING MODEL?
      • サービスメッシュはTCP/IP層の上の抽象レイヤーに位置するネットワークモデルです　
      • 基礎となるL3/L4ネットワークが存在し、ポイントツーポイントでバイトを配信できることを前提としています
      • (また、このネットワークは環境の他のすべての側面と同様に信頼性が低く、サービスメッシュもネットワーク障害を処理できる必要があると仮定します。)
      • いくつかの点で、サービスメッシュはTCP/IPに似ています。
      • TCPスタックがネットワークエンドポイント間で確実にバイトを配信する仕組みを抽象化するように、サービスメッシュはサービス間で確実に要求を配信する仕組みを抽象化します。
      • TCPのように、サービスメッシュは実際のペイロードやエンコード方法については気にしません。
      • アプリケーションは高レベルの目標(「AからBに何かを送信する」)を持ち、TCPのようなサービスメッシュの仕事は、途中の失敗を処理しながらこの目標を達成することです。
      • TCPとは異なり、サービスメッシュは、「動作させる」 以外に重要な目標を持っています。
      • アプリケーションランタイムに可視性と制御を導入するための、アプリケーション全体にわたる統一されたポイントを提供します
      • サービスメッシュの明白な目標は、目に見えない暗黙のインフラ領域から、エコシステムのファーストクラスメンバーの役割(サービスを監視、制御できる)にサービス間通信を移動させることです
    • WHAT DOES A SERVICE MESH ACTUALLY DO?
      • クラウドネイティブアプリケーションで確実にリクエストを配信することは、非常に複雑になります
      • Linkerdのようなサービスメッシュはこの複雑さを以下のような強力な手法で管理します
        • サーキットブレーカー
        • latency-aware load balancing
        • 最終的に一貫した(「アドバイザリ」)サービスディスカばり
        • リトライ
        • デッドライン
      • これらの機能はすべて連携して動作しなければならず、これらの機能とそれらが動作する複雑な環境とのインタラクションは非常に微妙なものになります
      • 例えば、Linkerdを介してサービスにリクエストがあった場合、非常にシンプルなイベントのタイムラインは次のようになります
          1. Linkerdは動的ルーティングルールを適用して、リクエスト送信者が意図したサービスを判断します
          2. リクエストをプロダクションまたはステージング中のサービスにルーティングする必要があるか？
          3. ローカルデータセンター内のサービスまたはクラウド上のサービス?
          4. テスト中の最新バージョンのサービスもしくは本番環境の検査済みの古いバージョンのサービス？ これらのルーティングルールはすべて動的に構成可能であり、グローバル及び任意のスライスのトラフィックに適用できます
          1. 正しい宛先が見つかると、Linkerdは関連するサービス検出エンドポイントからインスタンスの対応するプールを取得します。 この情報が実際にLinkerdが観測したものと異なる場合、Linkerdはどの情報源を信頼するかを決定します。
          1. Linkerdは、最近のリクエストの観測されたレイテンシを含む様々な要因に基づいて、高速応答を返す可能性の高いインスタンスを選択する Linkerdはインスタンスにリクエストを送信し、結果のレイテンシとレスポンスタイプを記録します
          1. インスタンスがエラーを一貫して返す場合、Linkerdはそのインスタンスを負荷分散プールから削除し、定期的にあとで再試行します(インスタンスに一時的な障害が発生しているなど)。
          1. リクエストの期限が経過した場合、Linkerdは追加の再リクエストで負荷を追加するのではなくプロアクティブにリクエストに失敗します
          1. Linkerdは上記の動作のあらゆる側面をメトリックと分散トレースの形で取り込み、集中型メトリクスシステムに送信します
      • これらの機能は、個別のレジリエンスとアプリケーション全体のレジリエンスを提供することを目的としていることに注意することが重要です
      • 大規模分散システムは、どのように構築されているかに関わらず、一つの明確な特性を持っています
      • システム全体の致命的な障害に拡大するための小さなローカライズされた障害の多くの小さな障害が存在する
      • サービスメッシュは、負荷を分散し、基盤となるシステムが限界に近づいたときに高速に処理しないことによってこれらのエスカレーションに対して保護するように設計する必要があります

  • Isito

  • Conduit

  • Minikube

    • https://github.com/kubernetes/minikube
    • ローカルでKubernetesを簡単に実行できるようにするためのツール
    • MinikubeはKubernetesを試してみたり、日常的に開発しようと思っているユーザーのために、ラップトップ上のVM内で単一ノードのKubernetesクラスタを実行する

  • Kubernetes

Prometheus

Spring

Java