「エンジニアリング組織論への招待」を読んだ

7月に転職して規模の大きいチームで働くことになった。 今まではスタートアップなどほとんど一人や数人で開発することが多く、 チームでの開発を行った経験が少ないため、勉強のためにエンジニアリング組織論への招待という本を読んでみた。

gihyo.jp

感想

  • 不確実性というテーマで一貫してかかれておりわかりやすかった。
    • いままでは考えようとしてもなにから考えればよいのかがわからなかったが、不確実性というキーワードを起点にできるようになった。
  • 一つのテーマを深く掘り下げるというよりも、さまざまなテーマについて触れているので、組織におけるさまざまな問題にフィットしそう。
  • 個人、1:1の関係、チーム、組織とさまざまな規模での話題について取り上げているので、困ったときはとりあえず問題の規模に応じてその部分を見ておけば良い。
  • 概念的な話だけでなく、具体的な実例が豊富ですぐにでも使ってみることができそう。

ElastiCacheRedisのCloudFormationで混乱したところを整理した

祝！はてなブログhttps化！🎉httpsになったのでブログを書いていこうと思います！

CloudFormationでElastiCache Redisクラスターを構築した時に混乱したことを整理してみました。長くなってしまったのでまとめだけ見れば問題ないと思います。

はじめに

CloudFormationでリソースを作成する場合、構築したいメインのリソースを中心にドキュメントを読んでいけば、関連するそれ以外の必要なリソースもわかるので、まずは中心となるリソースを見つけるのがおすすめです。

たとえば、Auroraの場合だとAWS::RDS::DBClusterというのがあるのでこれのプロパティに必要なリソースを定義していけば良いというのがわかります。

ElastiCacheの場合もDBなのでAuroraの設定に近い構成になると踏んでいました。Clusterっぽいリソースがあってそこに色々追加していく感じです。実際、AWS::ElastiCache::CacheClusterというリソースがあったのでこれを使えば良いんだろうと考えました。

AWS::ElastiCache::CacheCluster

以下がCacheClusterの設定例です。

  CacheCluster:
    Type: AWS::ElastiCache::CacheCluster
    Properties:
      AutoMinorVersionUpgrade: true
      Engine: redis
      EngineVersion: !Ref EngineVersion
      CacheNodeType: !Ref CacheNodeType
      CacheParameterGroupName: !Ref CacheParameterGroup
      CacheSubnetGroupName: !Ref CacheSubnetGroup
      Port: !Ref Port
      SnapshotRetentionLimit: !Ref SnapshotRetentionLimit 
      NumCacheNodes: !Ref NumCacheNodes
      VpcSecurityGroupIds:
        - !GetAtt CacheSecurityGroup.GroupId

これだけを見ると何も難しいところはなさそうです。CacheNodeTypeのノードがNumCacheNodes数だけ立ち上がるように見えますね。しかしながら、これを実行してクラスターを構築しようとするとNumCacheNodes should be 1 if engine is redisというエラーが出てStackの構築に失敗します。

原因は、エラーメッセージにあるとおりNumCacheNodesに1以外を設定したためです。NumCacheNodesという名前と直感的に反しますが、これは公式ドキュメントに書いてありました。

Redis 用 ElastiCache クラスターは、同じ役割を持つ 1 つまたは複数の Redis 用 ElastiCache ノードのコレクションです。プライマリノードはプライマリクラスター内に作成され、リードレプリカノードはリードレプリカクラスター内に作成されます。現在、1 つのクラスターは 1 つのノードのみを持つことができます。

つまり、現状1つのクラスターには1つのノードしか存在できないようです。

それではどうやってCloudFormationでElastiCacheのRedisクラスターを構築するかというと AWS::ElastiCache::ReplicationGroupテンプレートを使用します。

AWS::ElastiCache::ReplicationGroup

以下がAWS::ElastiCache::ReplicationGroupの実装例です。

  CacheReplicationGroup:
    Type: AWS::ElastiCache::ReplicationGroup
    Properties: 
      AutomaticFailoverEnabled: true
      CacheNodeType: !Ref CacheNodeType
      CacheParameterGroupName: !Ref CacheParameterGroup
      CacheSubnetGroupName: !Ref CacheSubnetGroup
      Engine: redis
      EngineVersion: !Ref EngineVersion
      NodeGroupConfiguration:
        - ReplicaCount: 1
      NumNodeGroups: 1 
      NumCacheClusters: 2 
      Port: !Ref Port
      ReplicasPerNodeGroup: !Ref NumCacheNodes 
      SecurityGroupIds:
        - !GetAtt CacheSecurityGroup.GroupId        
      SnapshotRetentionLimit: !Ref SnapshotRetentionLimit

大体はなんとなくわかる気がするのですが、この中の４つのプロパティの違いがわからなくて混乱しました。以下はそのプロパティ名とAWS Documentの説明です。

  • NumNodeGroups
    • この Redis (clustered mode enabled) レプリケーショングループのノードグループ (シャード) の数。Redis (clustered mode disabled) では、このプロパティを省略します。
  • NumCacheClusters
    • このレプリケーショングループのキャッシュクラスターの数。自動フェイルオーバーが有効な場合、1 より大きな値を指定する必要があります。
  • ReplicasPerNodeGroup
    • 各ノードグループ(シャード)のレプリカノードの数
  • NodeGroupConfiguration: ReplicaCount:
    • ノードグループのリードレプリカノードの数

全部似たような説明で違いがよくわからなかったので、調べて見ました。

NumNodeGroups

NumNodeGroupsはRedis (clustered mode enabled) レプリケーショングループのノードグループ (シャード) の数を指定します。

クラスタモードが有効なRedisのレプリケーショングループの場合、一つのレプリケーショングループには複数のノードを集めたノードクラスタ(シャードを)含んでいるのでその数を指定するための項目のようです。 クラスタモードを無効にしてRedisで動作させたい場合はこのプロパティを省略します。

Redis用ElastiCacheに出てくる概念はこちらの記事が参考になりました。 ElastiCache + Redis に出てくる概念と、クラスタモードごとの違い

NumCacheClusters

NumCacheClustersはレプリケーショングループのキャッシュクラスターの数です。 クラスタモードが無効の場合に設定します。 複数のシャードを指定(クラスタモード有効に)すると、このプロパティは無視されます。代わりに、ReplicasPerNodeGroup プロパティを使用するようです。

このプロパティと他の３つのプロパティは同時に指定することはできず、 指定してしまうと以下のようなエラーが出力されて構築に失敗します。

Property NumCacheCluster cannot be defined along with Properties
NumNodeGroups, ReplicasPerNodeGroup or NodeGroupConfiguration

ReplicasPerNodeGroup

各ノードグループ(シャード)のレプリカノードの数です。 こちらはNodeGroupConfigurationと同時には指定できません。 指定してしまうと以下のエラーが出ます。

Cannot specify both replicasPerNodeGroup and replicaCount.

NodeGroupConfiguration: ReplicaCount

NodeGroupConfigurationはノードグループの設定を指定するプロパティです。 レプリカ数だけでなく、アベイラビリティゾーンなどの設定も行えます。 ReplicaCountを指定することでノードグループのリードレプリカノード数を決めることができます。 このプロパティはクラスタモードが無効・有効どちらの場合でも使用できまが、 クラスタモードが有効(複数シャード)の場合は、シャード数分指定する必要があります。

      NumNodeGroups: 2
      NodeGroupConfiguration:
        - ReplicaCount: 1
        - ReplicaCount: 2

まとめ

  • AWS::ElastiCache::CacheClusterはひとつのノードだけ構築する際に使用する
  • AWS::ElastiCache::ReplicationGroupは複数のノードのクラスタを構築する際に使用する
    • クラスタモードが無効の場合(単一シャード)
      • NumCacheClustersかNodeGroupConfiguration: ReplicaCountを一つ指定する
    • クラスタモードが有効の場合(複数シャード)
      • NumNodeGroupsでシャード数を指定
      • ReplicasPerNodeGroupかNodeGroupConfiguration: ReplicaCountをシャード数分指定する

参考

今週勉強したことまとめ(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

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

今週はECSの使い方を手を動かしながら学んだ。 細かいドキュメントは読み込めていないので今後読んでいく必要があるが、 最終的にCircleCIでDockerイメージをビルドしECRにpush後、ecs-deployコマンドで開発環境にデプロイするという流れを自動化するまでできた。 作成したリソースを消す際にALB周りでつまったところがあったので、リソース削除時は最新の注意を払う。 今後まとめる際はリンクだけ貼るのではなく、少なくとも中身を一行ぐらいで説明するようにする。

AWS

ECS

  • EC2インスタンスのクラスターでDockerコンテナを実行できるサービス

  • ECS CLI

    • ローカル開発環境からのクラスター及びタスクの作成、更新、モニタリングを簡素化する高レベルなコマンド
    • DockerComposeファイルがサポートされている
    • インストール
      • MacOSの場合 sudo curl -o /usr/local/bin/ecs-cli https://s3.amazonaws.com/amazon-ecs-cli/ecs-cli-darwin-amd64-latest sudo chmod +x /usr/local/bin/ecs-cli ecs-cli --version
    • 設定 ecs-cli configure --region us-west-2 --access-key $AWS_ACCESS_KEY_ID --secret-key $AWS_SECRET_ACCESS_KEY --cluster ecs-cli-demo

  • ecs-deploy

  • サービス定義時に紐づけるロードバランサを間違えるとインスタンスがひとつもないターゲットグループをさしてしまうので注意

  • サービスを削除したい場合は以下の三段階の手順が必要
    • クラスター > サービスの設定でタスクの数を0にする
      • これをしないと自動でタスクが起動してしまうため
    • クラスター > タスクでタスクを停止する
    • クラスター > サービスでサービスの削除を実行する

  • クラスター内のインスタンスのリソースで足りない場合はタスクが起動しない

  • ECSでコンテナのrolling update

  • ECS運用のノウハウ
  • マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017

ALB

  • ヘルスチェックを設定しないと503
  • 同じセキュリティグループに関連付けられたインスタンスが相互に通信できるようにするには、そのためのルールを明示的に追加する必要がある
    • 送信元IPにセキュリティグループのidを指定する
  • パスベースのルーティングを変更したい場合は
    • EC2 > ロードバランサ > リスナーtab > ルールの表示/編集を押すと管理画面が表示される
    • まちがってターゲットグループをロードバランサに紐づけてしまった場合はここからパスごとにターゲットグループの紐づけを解除しなければ、ターゲットグループそのものを削除できない

Aurora

  • パラメータグループ
    • 何も指定しなければデフォルトのパラメータグループになる
    • デフォルトのパラメータグループは変更できないため作り直しになるので注意
    • Auroraの場合はクラスターパラメータとDBインスタンスパラメータの２種類がある

Docker

bitrise

  • アプリのビルド専用のCIサービス
  • 50$/月でビルドし放題

SideCI

  • コードレビューを自動でしてくれるCIサービス

SonarQube

SpringBoot

Play framework

MySQL

  • MySQLの文字コード事情
  • charset
    • utf8mb4
      • UTF-8で4バイト文字を扱うためのcharset
      • mysql特有
      • これを選んでおけば良い
  • collation
    • 文字の照合規則・照合順序
    • utf8mb4_general_ci
      • utf8mb4のデフォルトのcollation
      • ASCII大文字小文字を区別しない
      • 絵文字を区別しない
    • utf8mb4_bin
      • 全文字を区別する
    • utf8mb4_unicode_ ci
      • ASCII大文字小文字を区別しない
      • 絵文字を区別しない
      • ひらがな、かたかな、濁点有無、全角、半角を区別しない
  • MySQL Connector/Jプロパティリスト
  • 現在接続しているスレッド数を表示する
    • show status like 'Threads_connected';
    • Max_used_connections これまでに記録された同時接続数の最大値
    • Threads_connected 現在開いている接続の数
    • Threads_created 接続を処理するために生成されたスレッド数
    • Threads_running スリープ状態になっていないスレッド数

Java

英語

  • can be used when
    • ~の場合に使用できる

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

今週はAWS re:Inventが開催され様々な新サービスが発表された。 サービス数が多すぎて全部を追うことができていないが、 今回特に気になったのはコンテナ周りのサービスで Managed KubernetesのEKSとFargeteという二つのサービスが発表された。 アプリケーションの実行環境の選択肢が増え、より自社のサービスに適した構成を構築できるようになったが、 AWSのサービスを組み合わせて適切なインフラを設計する難易度がどんどん上がっている気がする。 今後は機械学習で最適なアーキテクチャを提案するサービスが出てきてくるのではないだろうか。 そのほかに今週は、あまりにも忘れていることが多いので システムプログラミング周りやネットワーク周りの基礎を勉強し直し始めた。

AWS

re:Invent

CloudFront

Aurora

  • DBクラスターが作成される
  • DBクラスターは以下の二つから構成される
    • 一つ以上のDBインスタンス
      • プライマリインスタンス
        • 読み込みと書き込みの操作をサポートし、クラスタボリュームに対する全てのデータ変更を実行する
        • Aurora DBクラスターには一つのプライマリインスタンスが存在する
      • Auroraレプリカ
        • 読み取りオペレーションのみをサポートする
        • DBクラスタは15までのレプリカを持つことができる
    • 一つのクラスタボリューム
      • インスタンスのデータを管理する
      • 複数のアベイラリティゾーンにまたがる単一の仮想データベースストレージボリューム
      • SSDドライブを利用する
      • 単一リージョンの複数のアベイラリビリティゾーン間のデータのコピー
      • ３つのアベイラビリティゾーン間で自動的にレプリケートされる
      • データベースのデータ量が増えるにつれて自動的に容量が増加する
      • 最大64TB
  • エンドポイント
    • Amazon AuroraDBクラスターのDBインスタンスに接続するための口
    • ホストアドレスとポートがコロンで区切られたURL
    • クラスターエンドポイント
    • 読み取りエンドポイント
      • Auroraレプリカに接続するためのエンドポイント
      • DBクラスターへの読み取り専用接続のロードバランシングを提供する
      • 接続リクエストを利用可能なレプリカに分散する
    • インスタンスエンドポイント
      • 特定のDBインスタンスに接続するDBインスタンス用のエンドポイント
      • DBクラスターへの接続の直接制御を提供する
        • 例えば、クライアントアプリケーションで接続ではなく読み取りワークロードによるロードバランシングが必要な場合
    • インスタンスエンドポイントを使用する前にクラスターエンドポイントか読み取りエンドポイントが使用できないか確認する
  • 信頼性
    • ストレージの自動修繕
      • ディスクボリュームの障害を自動的に検出し、すぐにそのセグメントを修繕する
      • 修復時に他のボリュームないのデータを使用して、修復されるデータが最新であるようにする
    • キャッシュのウォームアップ
      • データベースがシャットダウン後に起動した場合バッファプールキャッシュをウォームアップする
      • メモリ内のページキャッシュに保存された既知のクエリのページをバッファプールに事前ロードする
      • ウォームアップをしなくて良いのでパフォーマンスが向上する
      • ページキャッシュはデータベースとは別のプロセスで管理される
      • このため、データベースに障害が発生した場合でもページキャッシュはメモリの残り、バッファプールはデータベース起動時に最新の状態にウォームアップされる
    • クラッシュ回復
      • クラッシュから瞬時に回復する
  • クラスターの作成
  • [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

コンテナ

システムプログラム

  • http://www.coins.tsukuba.ac.jp/~syspro/2017/
  • http://www.coins.tsukuba.ac.jp/~yas/
  • OSとは
    • OSはハードウェアの違いを隠蔽し、ユーザがプログラムを実行するための使いやすい環境を提供する
    • ハードウェアを抽象化した概念を提供することで、いろいろなコンピュータで共通に使用できる実行環境を提供する
    • OSが提供する抽象概念
      • (ハードウェア機能) -> (抽象概念)
      • プロセッサ、メモリ -> プロセス
      • ストレージ -> ファイル、ディレクトリ
      • コンピュータ間の通信 -> プロセス間通信
      • 割り込み -> シグナル
      • コンピュータ共有時の保護 -> アクセス制御
  • API
  • シェル
    • CLIを通して、ユーザからのコマンドを受け付け、解釈・実行し、その結果を出力する機能を提供するプログラム
    • コマンドの入出力をファイルや別のコマンドにするリダイレクションやパイプという機能を提供する
      • 比較的単純な機能を持つ複数のコマンドを組み合わせて複雑な機能を実現することが可能
  • コマンド
    • ユーザがコンピュータに与える命令
    • UNIXはシェルから利用できる非常に多くのコマンドを提供している
    • コマンドはシェルとは別のプログラムの場合もあるし、シェルに組み込まれている場合もある
  • システムコール
    • OSカーネルの機能を直接呼び出すためのインタフェース
    • できるだけシンプルになるように設計されている
  • ライブラリ・ミドルウェア
    • プログラムの部品となる関数の集合
  • システムコールもライブラリもCプログラムから呼び出す場合はどちらも関数呼び出しの形態で使用できるため同じに見える
  • UNIXカーネル
    • プロセッサの特権モードというハードウェアの全てを制御できる動作モードで動作し、直接ハードウェアを制御するプログラム
    • UNIX環境で特権モードで動作するプログラムはカーネルだけ
    • その他のプログラムは、ユーザモードと呼ばれるハードウェアへのアクセスが制限された環境で動作する
  • ライブラリ関数とシステムコールの違い
    • 実行時にライブラリ関数はそれを使用するプログラムの一部となるが、カーネルは完全に独立したプログラムとして存在する
    • プログラムとライブラリは同じプロセス空間にある、しかしカーネルは別の場所(カーネル空間)にありプロセスからアクセスできないところで実行されている
    • プロセスはシステムコールを通じてのみカーネルの機能を使うことができる
    • プログラムからの入出力は結局はシステムコールを通じて実行される
    • ライブラリだけで実現される機能もある
      • 文字数を数えたり、文字列を比較したりといった、入出力を伴わないがプログラムでよく使われる部品となるような機能をライブラリは提供している
  • プロセス
    • プログラムを実行中のもの
    • 一つのプログラムを複数実行することができる
    • プログラムは、CPUが実行できる機械語命令とそれにより処理されるデータの集合がファイルに格納されたもの
    • プロセスは実行中の情報
  • manコマンド
    • man -k キーワードでキーワードに関連するコマンドを表示してくれる

Redis

Network

  • CIDR
    • アドレスクラスの概念を気にしないことで、IPアドレスの割り当てや経路選択などの自由度をあげる仕組み
    • IP空間を分割する仕組みの一つ
      • アドレスクラスだとBとCの間で大きさが違いすぎて非効率
      • ブロックの大きさを柔軟に変更できる
    • /16で65536のホスト

Spring Boot

  • Spring Boot外部設定

  • ロック待ち

    • SpringBoot/jUnit/MySQL/DBSetup/AssertDBで単体テスト実行時、テストが終了しなくなることがあった
    • 一つのテストケースだけでは発生しないが、複数のテストケースをまとめて実行した際に発生するためロック待ちをしていると考えられる
    • 参照系のメソッドをテスト時にはテストクラスに@Transactionアノテーションを付与することでロック待ちに陥ることがなくなった
    • 逆に更新系のメソッドに@Transactionをつけてしまうとテストが終了しなくなったのでアノテーションを外しておいた

MySQL

  • private subnetないのDBに接続して操作したい場合、Sequel Proで踏み台サーバ経由でアクセスできる
  • SQLモード
  • IFNULL(expr1, expr2)
    • expr1がNULL出ない場合、IFNULL()はexpir1を返し、それ以外の場合はexpr2を返す
    • expr2もNULLの場合はNULLを返す

キーボード

  • Barroco
    • Fn + Aでレイヤー切り替え

英語

  • presumably
    • おそらく
  • density
    • 密度
  • At the moment
    • 現時点では
  • comes at a cost
    • 高くつく
    • コストが必要となる
  • Elastic
    • 伸縮自在の
  • That being the case
    • それなら、だとすれば、そういうことなら
  • pure play
    • ~を専業とする

その他

  • 年金

    • 厚生年金(国民年金)控除証明書はハガキで送られてくる
      • 年末調整で使用するため捨てないこと
    • 控除証明書を紛失した場合は年金事務所で再発行できる
    • 転職などで途中で支払いが途切れている場合は控除証明書を発行できない

  • Heptio

    • Kubernetesを専業とする起業

  • Entrepreneur in Residence

  • 客員企業制度
    • 起業家が特定の企業に入社し、その企業で起業準備をする

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

勉強したことについてメモしたものを一週間ごとにまとめてみることにした。 ブログのネタになりそうなものがあれば、ここから記事にまとめるところまでいけると良い。 初回は2週間分になってしまっている。まとめ方が難しい。

Java

  • Arrays.asListは固定長のリストを生成するのでaddやremoveできない
    • new ArrayList<>(Arrays.asList())を使う
  • lombokで@Dataをつけるときは@Builderの後につけないとGetterやSetterが正しく作成されずエラーになる
  • synchronizedブロック
    • 他のスレッドから割り込まれないようにブロックする
  • KeyStore
  • keytool
    • jdkが提供するキーストアを操作するツール
    • キーストアから秘密鍵を抽出する機能は持たない

Spring Framework

  • ErrorControllerインタフェースは@Controllerがエラーのレンダリングに使用されていることを示すためのマーカーインタフェース
    • 主にセキュアにする必要のないエラーパスを知るために使用される
  • SpringBootはデフォルトで全てのエラーをハンドルする/errorにマッピングする
    • /errorをハンドリングするコントローラを実装すればそこでエラーレスポンスをいじれる
  • server.error.whitelabel.enabled=falseを設定することでデフォルトのエラーページを非表示にできる
  • @ResponseStatusは返すべきステータスコードと理由とともにメソッドや例外をマークする
  • SpringBoot Actuator
    • アプリのモニタリングや管理機能を提供するSpringBootのサブプロジェクト
  • NamedJdbcTemplate
    • NamedParameterJdbcOperationsをimplementしている
    • JDBCの操作の基本セットをもつテンプレートクラス
    • '?'プレースホルダーそのものではなく名前付きパラメータを使用することができる
    • 実行時に名前付きパラメータの解決を行い、あとはJdbcTemplateにデリゲートしている

CQRS

  • コマンドクエリ責務分離
  • 質問することで答えを変えてはいけない
  • 全ての基本操作がコマンドかクエリになる
    • コマンドはシステムの状態を変更する
    • クエリは状態を変更せず報告する

Editor

mysql

Redis

Test

  • unit test
    • テストの定義「ある条件下においてソフトウェアの振る舞いを記録し、その記録が期待される結果となることを検証するプロセス」
    • テストケース -> ひとつのテスト項目のこと

英語

  • via: ~することで
  • with: 使用して

DNS

AWS

ECS

ECR(EC2 Container Registory)

  • AWSが提供するDockerレジストリサービス
  • レジストリがイメージリポジトリとイメージを管理する
  • Error response from daemon: Get https://.dkr.ecr.ap-northeast-1.amazonaws.com/v2/: proxyconnect tcp: dial tcp : getsockopt: connection refusedが出たらDocker再起動でなおった

AWS Shield Advanced

Docker

  • docker buildコマンドはDockerfileとコンテクストによってイメージを構築する

  • コンテクスト

    • dockerコマンドを実行するディレクトリ、ディレクトリに含まれる内容物
    • ビルドプロセスの初めにコンテクストがDockerデーモンに送信される
    • PATH(ローカルフィル上のディレクトリ)やURL(Gitリポジトリの場所)を指定できる
    • Dockerfile上でCOPYなどを行う場合はコンテクスト外のリソースを指定することはできない
    • dcoker build コンテキストPATH -f DockerファイルでDockerfileが保存されている場所とは別の場所をコンテキストに指定できる

  • tag

    • 同じタグをつけると新しいimageにつけ変わる

  • ネットワーク機能

    • Docker ネットワーク機能の概要
    • ユーザが自分自身でネットワークを定義し、コンテナを接続できる
    • docker network lsでネットワークのリストを表示
    • デフォルトで以下の三つのネットワークが生成される
      • brigdge
      • null
      • host
    • docker run --network=<NETWORK>でコンテナがどのネットワークに接続するかを指定できる
      • このオプションを指定しない限りデフォルトのbridgeに接続される

  • docker-compose

    • depends_onとlinkの違い
      • v2では違いはない、v1ではdepends_onはコンテナの作成順序と依存関係を解決するのに対して linkはそれに加えてエイリアス名を使用してコンテナにアクセスできるようになる

Circle CI

bash

fish shell

  • && はfishでは; andと書く

Code coverage

Mac

  • ipコマンドをインストールする方法

    • brew install iproute2mac

  • KarabinerElementsで外部キーボード接続時に内部キーボード無効化

    • Devices > Disable the buildin....

iPhone

  • iPhone X
    • アニ文字
      • 自分の顔の表情を反映させたアニメーションキャラクターアイコン
      • メッセージAppで作成・共有できる
      • サマーウォーズ的な世界観が実現するかも？

Network

  • ブリッジ

    • レイヤー2で異なるネットワーク間を通信できるようにする装置

  • NIC(ネットワークインタフェースカード)

    • eth0, eth1, eth2...という順番で名前がつく
    • lo0
      • ネットワークのテストに使用できるように用意された仮想インタフェース
      • NICがなくてもこのloは表示される
      • 127.0.0.1がIPアドレスとして自動で割り当てられる
    • gif0(generic tunnel interface)
      • IPv6/IPv4トンネリングを行うときに使うインタフェース
    • stf0(6to4 tunnel interface)
      • IPv6パケットをIPv4ネットワークにルーティングするためのインタフェース
      • gifは両方できる
    • p2p0
    • awdl0
      • Apple Wireless Direct Link
      • Apple機器と無線通信を行うためのインタフェース
    • utun0

  • MTU

    • ネットワークにおいて1回の転送（1フレーム）で送信できるデータの最大値を示す伝送単位

高速化

  • dev.to
    • 海外版Qiitaのようなサイト
    • とても早い
    • 理由
      • Fastlyでキャッシュ
      • Cloudinaryで画像をwebpに変換し配信
      • styleのレンダリングをしない

その他

  • C10K問題
    • 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
    • TheC10kProblem

Spring Boot開発時に見ると良い記事まとめ

SpringBoot Java Docker

Spring Boot開発時に参考になるドキュメントのまとめです。

general

トランザクションマネージャ

Bean

Docker

Lombok

  • setter/getterを作ってくれるやつ
  • builderパターンをやってくれる

日付

ログ

Gradle

Config

Controller

アノテーションまわり