OmniAICreator/Qiita-1.07M huggingface dataset:
Envoy: トレーシング

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## トレーシング
### 概要

分散トレーシングを使用すると、開発者は大規模なサービス指向アーキテクチャでコールフローを視覚化することができます。シリアライゼーション、並列処理、および待ち時間の原因を理解する上で非常に貴重なことがあります。 Envoyは、システム全体のトレーシングに関連する3つの機能をサポートしています。

- リクエストIDの生成：Envoyは必要に応じてUUIDを生成し、x-request-id HTTPヘッダーを生成します。アプリケーションは、トレーシングだけでなく統合ロギングのためにx-request-idヘッダーを転送できます。
- クライアントトレーシングIDの参加：x-client-trace-idヘッダーを使用して、信頼されていない要求IDを信頼された内部のx-request-idに参加させることができます。
- 外部トレーシングサービスの統合：Envoyはプラグイン可能な外部トレーシング視覚化プロバイダをサポートしています。これらは2つのサブグループに分けられます。
- LightStep、Zipkin、またはZipkin互換のバックエンド（Jaegerなど）、およびDatadogなど、Envoyコードベースの一部である外部トレーサ。
- Instanaのように、サードパーティ製のプラグインとして提供される外部トレーサ。

他のトレーシングプロバイダのサポートを追加するのは難しくありません。

### トレーシングを開始する方法

要求を処理するHTTP接続マネージャには、トレーシングオブジェクトを設定する必要があります。トレーシングを開始する方法はいくつかあります。

- x-client-trace-idヘッダーを介した外部クライアントによる。
- x-envoy-force-traceヘッダーを介した内部サービスによる。
- random_samplingランタイム設定によってランダムにサンプリングされます。

ルータフィルタはstart_child_spanオプションによって出力コールのための子スパンを作成することもできます。

### トレーシングコンテキストの伝播

Envoyは、メッシュ内のサービス間の通信に関するトレーシング情報を報告する機能を提供します。ただし、コールフロー内のさまざまなプロキシによって生成されたトレーシング情報を相互に関連付けることができるようにするには、サービスはインバウンド要求とアウトバウンド要求の間に特定のトレーシングコンテキストを伝播する必要があります。

どのトレーシングプロバイダーが使用されている場合でも、サービスはx-request-idを伝播して、呼び出されたサービス間でのログ記録を有効にする必要があります。

トレーシングプロバイダーは、スパン間の親子関係（論理作業単位）を理解できるようにするために、追加のコンテキストも必要とします。これは、LightStep（OpenTracing API経由）またはZipkinトレーサをサービス自体の中で直接使用して、着信要求からトレーシングコンテキストを抽出し、それを後続の発信要求に挿入することで実現できます。このアプローチにより、サービスはサービス内で行われている作業を記述した追加のスパンを作成することもできます。これは、エンドツーエンドのトレーシングを調べるときに役立ちます。

あるいは、トレーシングコンテキストはサービスによって手動で伝播されることができます。

- LightStepトレーサを使用する場合、Envoyは他のサービスにHTTPリクエストを送信しながらx-ot-span-context HTTPヘッダを伝播するためにサービスに依存します。
- Zipkinトレーサを使用する場合、Envoyはサービスに依存してB3 HTTPヘッダ（x-b3-traceid、x-b3-spanid、x-b3-parentpanid、x-b3-sampling、およびx-b3-flags）を伝達します。 x-b3-samplingヘッダーは、特定の要求に対するトレーシングを有効または無効にするために外部クライアントからも提供されます。さらに、より圧縮されたフォーマットである単一のb3ヘッダー伝播フォーマットがサポートされています。
- Datadogトレーサーを使用する場合、EnvoyはDatadog固有のHTTPヘッダー（x-datadog-trace-id、x-datadog-parent-id、x-datadog-sampling-priority）を伝達するサービスに依存しています。

### 各トレーシングに含まれるデータ

エンドツーエンドのトレーシングは、1つ以上のスパンで構成されています。スパンは、開始時刻と期間を持ち、それに関連付けられたメタデータを含むことができる論理作業単位を表します。 Envoyによって生成された各スパンには、以下のデータが含まれています。

- --service-clusterによって設定された発信元サービスクラスター。
- リクエストの開始時間と期間
- --service-nodeを介して設定された発信ホスト。
- x-envoy-downstream-service-clusterヘッダーを介して設定されたダウンストリームクラスター。
- HTTP URL
- HTTPメソッド
- HTTPレスポンスコード
- システム固有のメタデータをトレーシングします。

スパンには、呼び出されたサービスのホストとしてデフォルトで定義されている名前（または操作）も含まれています。ただし、これはroute.Decoratorを使ってカスタマイズできます。名前はx-envoy-decorator-operationヘッダーを使用して上書きすることもできます。

Envoyは自動的にスパンをトレーシングコレクタに送ります。トレーシングコレクタによっては、グローバルに一意なリクエストID x-request-id（LightStep）やトレーシングID設定（ZipkinとDatadog）などの共通情報を使用して複数のスパンがステッチされます。見る

v2 APIリファレンス

Envoyでトレーシングを設定する方法の詳細については。
GASでセルの値を取得、変更、削除

##はじめに
GAS勉強中で、<b>「アウトプットはインプットからはじまっている」</b>と思っている今日この頃。
部下にも色々業務を覚えるときや、MTGなどで話しを聞いている時は必ず上記お話と、理由を説明します。

そんなこんなで、ビジボットというサイトで記事を書きながら勉強しているわけですが。。。
【ビジボット】https://bzbot.work
【記事レシピ】https://bzbot.work/2019/05/22/gas-recipe/

やってみて、色々学ぶことが多く勉強できているなと感じてます。
例えばAnalyticsを入れているから、ユーザ数が見えるし、SearchConsoleを入れているからどういうキーワードでサイトが上位に表示されているか、などが視覚的にわかるからです。

でも、視覚的にわからなかったらここまでのモチベーションを保ちつつ提供できていない為、読んでくれる人、読まなかったにせよ検索してサイトに来て直帰しちゃった方もほんと感謝です。自分もやりたいこと探しているときに、クリックして「あ、違うな」って思ったらすぐ離脱しちゃいますし。。

そうやって極小サイトながらも色々な勉強ができているのはみなさんのおかげです。。。。笑


##本題
今回はタイトルにある通り、セルの基本操作について書いていきます。
すでに記事にされているので、細かい内容は省いちゃいます。

###セルの値を取得
詳細はこちら ➡️ https://bzbot.work/2019/05/22/gas-getvalue/
セルの値で2列目2行目には「ビジボットイチロウ」というワードが入力されてます。
この値を取得する方法はシンプルに以下です。
※複数のセル範囲を取得する場合は「getValues」を使います（詳細URLでサンプルあり）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/363116/7ddc08ae-ba5b-cea0-09f6-21ce80388b6b.png)


```Javascript:GAS
function myFunction() {
  // 現在開いているスプレッドシートを取得
  var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
 
  // 現在開いているシートを取得
  var sheet = spreadsheet.getActiveSheet();
  
  // 指定したセルの値を取得
  var getVal = sheet.getRange(2,2).getValue();
  
  // 取得した結果をログに表示
  Logger.log('getRange(2,2):' + getVal);
}
```

```text:log
[19-05-20 02:06:04:063 JST] getRange(2,2):ビジボットイチロウ
```

###セルの値を変更
詳細はこちら ➡️ https://bzbot.work/2019/05/22/gas-setvalue/
セルの値で2列目2行目には「ビジボットイチロウ」というワードが入力されてます。
この値を「ビジボット」という値に変更する方法はシンプルに以下です。
※複数のセル範囲を値を反映する場合は「setValues」を使います（詳細URLでサンプルあり）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/363116/5acd1de7-4ea0-4017-e31f-e9d4373a04ae.png)


```Javascript:GAS
function myFunction() {
  // 現在開いているスプレッドシートを取得
  var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
  
  // 現在開いているシートを取得
  var sheet = spreadsheet.getActiveSheet();
  
  // 指定したセルの値を変更する
  sheet.getRange(2,2).setValue('ビジボット');
}
```

###セルの値を削除
詳細はこちら ➡️ https://bzbot.work/2019/05/24/gas-clear/
セルの値で2列目2行目には「ビジボットイチロウ」というワードが入力されてます。
この値を削除する方法はシンプルに以下です。
※複数のセル範囲を取得する場合は「getValues」を使います（詳細URLでサンプルあり）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/363116/e1ff19b4-48cb-2943-6e0f-29da9546c409.png)


```Javascript:GAS
function myFunction() {
  // 現在開いているスプレッドシートを取得
  var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
  // 現在開いているシートを取得
  var sheet = spreadsheet.getActiveSheet();
  
  // 指定したセルの値を取得
  var getVal = sheet.getRange(2,2).getValue();
  Logger.log('clear前のgetVal:' + getVal);
  
  // 指定したセルの値を削除
  sheet.getRange(2,2).clear();
  
  // 指定したセルの値を取得
  var getVal = sheet.getRange(2,2).getValue();
  Logger.log('clear後のgetVal:' + getVal);
}
```

```text:log
[19-05-23 02:27:30:674 JST] clear前のgetVal:ビジボットイチロウ
[19-05-23 02:27:31:055 JST] clear後のgetVal:

```

###ログって
GASの勉強していてほんとに助かっているログ機能。
「Logger.log();」って記載するだけで簡単にログ画面を表示することができるので重宝してます！

よくコメントを書いておかないと「なんだこのコードは！」って思ったら自分が書いたなんてネタかな？って思ってたワードをよく聞くけど、コメント替わりにログで表示するとより便利。
明日の自分は全くの他人だと思って、こういうところはしっかりとしていきたい。
※GASの稼働上限の時間を加味して入れすぎてもよろしくないので、そこはよしなに...笑
https://bzbot.work/2019/05/29/gas-log/


余談で以下スプレッドシートのシート名を指定する方法です。
ぜひGAS初めての方はみてみてください。
https://bzbot.work/2019/05/24/gas-getsheetbyname/
Envoy: ランタイム設定

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## ランタイム設定

Envoyは「ランタイム」設定（「機能フラグ」および「決定」とも呼ばれます）をサポートしています。 Envoyを再起動したり、プライマリ設定を変更したりすることなく、動作に影響を与える設定を変更することができます。現在サポートされている実装はファイルシステムファイルのツリーを使用します。 Envoyは設定されたディレクトリ内のシンボリックリンクスワップを監視し、それが起こるとツリーをリロードします。このタイプのシステムは、大規模な分散システムで非常に一般的に展開されています。他の実装は実装が難しくありません。サポートされているランタイム構成設定は、操作ガイドの関連セクションに記載されています。 Envoyはデフォルトのランタイム値と「null」プロバイダで正しく動作するため、Envoyを実行するためにそのようなシステムが存在する必要はありません。

実行時設定
Envoy: 統計

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## 統計

Envoyの主な目的の1つは、ネットワークをわかりやすくすることです。 Envoyはそれがどのように設定されているかに応じて多数の統計を出します。一般に、統計は3つのカテゴリに分類されます。

- ダウンストリーム：ダウンストリーム統計は、着信接続/要求に関連しています。これらはリスナー、HTTP接続マネージャ、TCPプロキシフィルタなどによって発行されます。
- アップストリーム：アップストリーム統計は発信接続/要求に関連しています。それらは、接続プール、ルーターフィルター、TCPプロキシーフィルターなどによって発行されます。
- サーバー：サーバー統計は、Envoyサーバーインスタンスがどのように機能しているかを示します。サーバーの稼働時間や割り当てられたメモリの量などの統計は、ここで分類されます。

単一のプロキシシナリオでは通常、ダウンストリーム統計とアップストリーム統計の両方が使用されます。 2つのタイプはその特定のネットワークホップの詳細図を得るのに使用することができます。メッシュ全体の統計情報から、各ホップおよびネットワーク全体の健全性に関する非常に詳細な情報が得られます。発行された統計は、操作ガイドに詳細に文書化されています。

v2 API以降、Envoyにはカスタムのプラガブルシンクをサポートする機能があります。 Envoyには、いくつかの標準的なシンク実装が含まれています。一部のシンクは、タグ/ディメンションを使用した統計の発行もサポートしています。

Envoy内およびドキュメント全体で、統計は標準的な文字列表現によって識別されます。これらの文字列の動的部分は取り除かれてタグになります。ユーザーはタグ指定子設定を介してこの動作を設定できます。

Envoyは統計として3種類の値を出力します。

- Counters：増加するだけで減少することのない符号なし整数。たとえば、リクエスト総数。
- ゲージ：増減する符号なし整数。たとえば、現在アクティブな要求です。
- ヒストグラム：値のストリームの一部である符号なし整数。その後、コレクターによって集約され、最終的に要約されたパーセンタイル値が得られます。たとえば、アップストリーム要求時間。

内部的には、カウンターとゲージはバッチ処理され、定期的にフラッシュされてパフォーマンスが向上します。ヒストグラムは受け取ったとおりに書き込まれます。注：以前はタイマーと呼ばれていたものが、ヒストグラムになりました。2つの表現の唯一の違いは単位です。

v2 APIリファレンス
Envoy: グローバルレート制限

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## グローバルレート制限

分散型回路遮断は、分散型システムのスループットを制御する上で一般的に非常に効果的ですが、それほど効果的ではなくグローバルなレート制限が望まれる場合があります。最も一般的なケースは、多数のホストが少数のホストに転送しており、平均リクエスト待ち時間が短い場合（例えば、データベースサーバへの接続／リクエスト）である。ターゲットホストがバックアップされると、ダウンストリームホストがアップストリームクラスタに負担をかけます。このシナリオでは、システムが通常の要求パターンの間は正常に動作するが、それでもシステムに障害が発生したときのカスケード障害を防止するように、各ダウンストリームホストに十分な回路遮断制限を設定することは非常に困難です。グローバルレート制限はこの場合のためのよい解決策です。

Envoyは、グローバルなgRPCレート制限サービスと直接統合しています。定義されたRPC / IDLプロトコルを実装する任意のサービスを使用することができますが、LyftはRedisバックエンドを使用するGoで書かれた参照実装を提供します。 Envoyのレート制限統合には、次の機能があります。

- ネットワークレベルレート制限フィルタ：Envoyは、フィルタがインストールされているリスナー上の新しい接続ごとにレート制限サービスを呼び出します。この設定では、レート制限をオンに設定する特定のドメインと記述子を指定しています。これは、リスナーを通過する1秒あたりの接続数をレート制限するという最終的な効果があります。構成の参照
- HTTPレベルレート制限フィルタ：Envoyは、フィルタがインストールされていて、ルートテーブルがグローバルレート制限サービスを呼び出すように指定しているリスナ上の新しいリクエストごとにレート制限サービスを呼び出します。ターゲットアップストリームクラスタへのすべての要求、および発信元クラスタからターゲットクラスタへのすべての要求はレート制限できます。構成の参照

レート制限サービスの設定
Envoy: サーキットブレイキング

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## サーキットブレイキング

サーキットブレイキングは分散システムの重要な構成要素です。すぐに失敗し、できるだけ早く下流にバックプレッシャーをかけるのが、ほとんどの場合より良いです。 Envoyメッシュの主な利点の1つは、Envoyが各アプリケーションを個別に設定してコーディングするのではなく、ネットワークレベルで回線遮断の制限を強制することです。 Envoyは、さまざまな種類の完全分散型（調整されていない）のサーキットブレイキングをサポートしています。

- クラスタ最大接続数：Envoyがアップストリームクラスタ内のすべてのホストに対して確立する最大接続数。 HTTP / 2は各ホストへの単一の接続を使用するため、実際にはこれはHTTP / 1.1クラスタにのみ適用可能です。このサーキットブレーカがオーバーフローすると、クラスタのupstream_cx_overflowカウンタが増加します。
- クラスター最大保留要求数：接続プール接続の待機中にキューに入れられる要求の最大数。 HTTP / 2要求は単一の接続を介して送信されるので、要求は直後に多重化されるため、このサーキットブレーカは最初の接続が作成されたときにのみ有効になります。 HTTP / 1.1の場合、リクエストをすぐにディスパッチするのに十分なアップストリーム接続が利用できないときはいつでも、リクエストは保留中のリクエストのリストに追加されるので、このサーキットブレーカはプロセスの存続期間中有効です。このサーキットブレーカがオーバーフローすると、クラスタのupstream_rq_pending_overflowカウンタが増加します。
- クラスタ最大要求数：クラスタ内のすべてのホストに対して同時に未解決になる可能性がある要求の最大数。 HTTP / 1.1クラスタは最大接続数のサーキットブレーカによって管理されているため、実際にはこれはHTTP / 2クラスタに適用できます。このサーキットブレーカがオーバーフローすると、クラスタのupstream_rq_pending_overflowカウンタが増加します。
- クラスタの最大アクティブ再試行回数：クラスタ内のすべてのホストに対して同時に未解決になることができる最大再試行回数。一般に、散発的な失敗に対する再試行は許可されますが、全体的な再試行回数が爆発して大規模なカスケード失敗を引き起こすことがないように、積極的に回線を切断することをお勧めします。このサーキットブレーカがオーバーフローすると、クラスタのupstream_rq_retry_overflowカウンタが増加します。
- クラスタ最大同時接続プール：同時にインスタンス化できる最大接続プール数。 Original Src Listener Filterなどの一部の機能では、無制限の数の接続プールを作成できます。クラスタがその同時接続プールを使い果たすと、アイドル状態のクラスタを取り戻そうとします。それができない場合は、サーキットブレーカがオーバーフローします。これは、接続プールがタイムアウトしないという点でクラスタ最大接続数とは異なりますが、通常、接続プールはタイムアウトします。接続は自動的にクリーンアップされます。接続プールはしません。接続プールが機能するには、少なくとも1つのアップストリーム接続が必要であるため、この値はクラスタの最大接続数以下にする必要があります。このサーキットブレーカがオーバーフローすると、クラスタのupstream_cx_pool_overflowカウンタが増加します。

各回線遮断制限は設定可能で、アップストリームクラスタごとおよび優先順位ごとに追跡されます。これにより、分散システムのさまざまなコンポーネントを個別に調整し、さまざまな制限を設けることができます。サーキットブレーカが開くまでに残っているリソースの数を含む、これらのサーキットブレーカの稼働状態は、統計によって観察できます。

サーキットブレイクによりHTTPリクエストの場合にはx-envoy-overloadのヘッダがルータフィルタによって設定されることに注意してください。
Envoy: 異常値検出

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## 異常値検出

異常値の検出と排除は、アップストリームクラスタ内のいくつかのホストが他のホストとは異なるパフォーマンスを示しているかどうかを動的に判断し、それらを正常な負荷分散セットから削除するプロセスです。パフォーマンスは、連続した失敗、一時的な成功率、一時的な待ち時間など、さまざまな軸に沿っている可能性があります。異常値の検出は、受動的なヘルスチェックの一種です。 Envoyは積極的な健康診断もサポートしています。パッシブヘルスチェックとアクティブヘルスチェックは、一緒にまたは個別に有効にでき、アップストリームヘルスチェックソリューション全体の基盤を形成します。

### 排出アルゴリズム

異常値検出のタイプに応じて、排出はインラインで（たとえば連続5xxの場合）または指定された間隔で（たとえば定期的な成功率の場合）実行されます。排出アルゴリズムは次のように機能します。

- ホストは異常値と判断されます。
- ホストが削除されていない場合、Envoyはすぐにホストを削除します。それ以外の場合は、排出されたホストの数が許可されたしきい値（outlier_detection.max_ejection_percent設定で指定）を下回っていることを確認します。排出されたホストの数がしきい値を超えると、そのホストは排出されません。
- ホストは数ミリ秒の間排出されます。排出とは、ロードバランサがパニックに陥っている場合を除き、ホストが異常とマークされ、ロードバランシング中に使用されないことを意味します。ミリ秒数は、outlier_detection.base_ejection_time_ms値にホストが排出された回数を掛けたものです。これが原因で、ホストが失敗し続けると、ホストはどんどん排出されます。
- 排出されたホストは、排出時間が経過した後で自動的に稼働状態に戻ります。一般に、異常値の検出は、包括的なヘルスチェックソリューションのためのアクティブヘルスチェックと一緒に使用されます。

### 検出タイプ

Envoyは、以下の異常値検出タイプをサポートしています。

#### 連続5xx

上流のホストが5xxの連続した数を返すなら、それは排出されます。この場合、5xxは実際の5xx応答コード、またはHTTPルーターがアップストリームに代わって1を返すイベント（リセット、接続失敗など）を意味することに注意してください。排出に必要な連続5xxの数は、outlier_detection.consecutive_5xx値によって制御されます。

#### 連続ゲートウェイ障害

上流のホストが連続した「ゲートウェイエラー」（502、503、または504のステータスコード）を連続して返した場合、それは排出されます。これには、HTTPルーターがアップストリームの代わりにこれらのステータスコードの1つを返す原因となるイベント（リセット、接続失敗など）が含まれることに注意してください。取り出しに必要な連続ゲートウェイ障害の数は、outlier_detection.consecutive_gateway_failure値によって制御されます。

#### 成功率

成功率ベースの異常値排除は、クラスタ内のすべてのホストからの成功率データを集計します。次に、一定の間隔で、統計的な異常値の検出に基づいてホストを除外します。集約間隔中の要求量がoutlier_detection.success_rate_request_volume値より小さい場合、成功率の異常値排出はホストに対して計算されません。さらに、間隔内の最小要求要求量を持つホストの数がoutlier_detection.success_rate_minimum_hosts値より少ない場合、クラスターの検出は実行されません。
### 排出イベントログ

外れ値排出イベントのログは、オプションでEnvoyによって生成することができます。グローバル統計では、どのホストが排除されているのか、またその理由について十分な情報が提供されないため、これは日常業務で非常に役立ちます。ログは、プロトタイプベースのOutlierDetectionEventメッセージのダンプとして構造化されています。排出イベントロギングは、Cluster Managerの異常値検出設定で設定されます。

### 構成の参照

- クラスタマネージャのグローバル設定
- クラスタ構成ごと
- 実行時設定
- 統計の参照
Envoy: コネクションプーリング

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## コネクションプーリング

HTTPトラフィックの場合、Envoyは基礎となるワイヤプロトコル（HTTP / 1.1またはHTTP / 2）の上に階層化された抽象接続プールをサポートします。利用するフィルタコードは、基礎となるプロトコルが真の多重化をサポートしているか否かを意識する必要はない。実際には、基礎となる実装は以下の高水準の特性を持ちます。

### HTTP/1.1

HTTP / 1.1接続プールは、必要に応じて上流のホストへの接続を取得します（回線遮断限界まで）。接続が前の要求の処理を終了したか、または新しい接続が最初の要求を受け取る準備ができたために、要求は使用可能になったときに接続にバインドされます。 HTTP / 1.1接続プールはパイプラインを使用しないため、アップストリーム接続が切断された場合に単一のダウンストリーム要求のみをリセットする必要があります。

### HTTP/2

HTTP / 2接続プールは、上流ホストへの単一接続を獲得します。すべての要求はこの接続を介して多重化されています。 GOAWAYフレームを受信した場合、または接続が最大ストリーム制限に達した場合、接続プールは新しい接続を作成して既存のものを排出します。 HTTP / 2は、切断されても接続がまれにしか発生しないため、推奨される通信プロトコルです。

### ヘルスチェックのやりとり

Envoyがアクティブまたはパッシブヘルスチェック用に設定されている場合、すべての接続プール接続は、使用可能状態から使用不可状態に移行するホストに代わって閉じられます。ホストが負荷分散ローテーションに再び入ると、（ECMPルートまたは他の理由で）悪いフローを回避する可能性を最大にする新しい接続を作成します。
Envoy: クラスタマネージャ

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## クラスタマネージャ

Envoyのクラスタマネージャは、設定されたすべてのアップストリームクラスタを管理します。 Envoy 設定にリスナをいくつでも含めることができるのと同様に、設定には独立して設定された上流クラスタをいくつでも含めることができます。

上流のクラスタとホストは、任意の数の異なるプロキシタスクに使用できることから、上流のクラスタとホストはネットワーク/HTTP フィルタスタックから抽象化されます。クラスタマネージャは、フィルタが上流クラスタへの L3/L4 接続、または上流クラスタへの抽象 HTTP 接続プールへのハンドルを取得することを可能にする API をフィルタスタックに公開します（上流ホストが HTTP/1.1 または HTTP/2 をサポートするかどうか）。隠されています）。フィルタステージは、L3/L4 接続と新しい HTTP ストリームのどちらが必要かを決定します。クラスタマネージャは、どのホストが利用可能で正常かを知ること、負荷分散、アップストリーム接続データのスレッドローカルストレージの複雑さをすべて処理します。シングルスレッド、アップストリーム接続タイプ（ TCP/IP、UDS ）、該当する場合はアップストリームプロトコル（ HTTP/1.1、HTTP/2 ）などと書かれています。

クラスタマネージャに認識されているクラスタは、静的に設定することも、クラスタ検出サービス（ CDS ）API を介して動的に取得することもできます。動的クラスター・フェッチにより、より多くの構成を中央構成サーバーに保管できるようになるため、Envoyの再始動および構成配布が少なくて済みます。

- クラスタマネージャの設定
- CDS の設定

### クラスタウォーミング

クラスタがサーバー起動時とCDS経由の両方で初期化されると、それらは「ウォームアップ」されます。これは、次の操作が行われるまでクラスタが使用可能にならないことを意味します。

- 初期サービス発見負荷（例えば、DNS 解決、EDS 更新など）。
- アクティブヘルスチェックが設定されている場合、初期アクティブヘルスチェックは合格です。 Envoy は、検出された各ホストにヘルスチェック要求を送信して、最初のヘルス状態を判断します。

前の項目では、Envoy がクラスタをトラフィックサービスに使用し始める前に、そのクラスタを正確に把握できるようにしています。

クラスタの温暖化について議論するとき、クラスタが「利用可能になる」とは、

- 新しく追加されたクラスターの場合、そのクラスターは温められるまで残りの Envoy には存在しないように見えます。つまり、クラスタを参照する HTTP ルートは、404または503のいずれかになります（構成によって異なります）。
- 更新されたクラスタの場合、古いクラスタは存在し続け、トラフィックを処理します。新しいクラスタがウォームアップされると、トラフィックの中断が発生しないように、古いクラスタとアトミックに交換されます。
Envoy: WebSocket と HTTP のアップグレード

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## WebSocket と HTTP のアップグレード

Envoy Upgrade のサポートは主に WebSocket を対象としていますが、WebSocket 以外のアップグレードにも使用できます。アップグレードは、HTTP ヘッダーとアップグレードペイロードの両方を HTTP フィルタチェーンを介して渡します。カスタムフィルタチェーンの有無にかかわらず upgrade_configs を設定できます。 upgrade_type のみが指定されている場合、アップグレードヘッダー、要求と応答の本文、および WebSocket ペイロードの両方がデフォルトの HTTP フィルタチェーンを通過します。アップグレードペイロードに HTTP 専用フィルタを使用しないようにするには、特定のアップグレードタイプ用にカスタムフィルタを設定します。これには、ルータフィルタのみを使用して WebSocket データをアップストリームに送信することが含まれます。

アップグレードはルートごとに有効または無効にできます。以下に示すように、ルートごとの有効化/無効化は自動的に HttpConnectionManager の設定を上書きしますが、カスタムフィルタチェーンは HttpConnectionManager ごとにのみ設定できます。

| HCMアップグレード有効化 | ルートアップグレード有効化 | アップグレード有効化 |
| --- | --- | --- |
| T（デフォルト）| T（デフォルト）T |
| T（デフォルト）| F | F |
| F | T（デフォルト）| T |
| F | F | F |

アップグレードの統計はすべてまとめられているため、WebSocket の統計は downstream_cx_upgrades_total や downstream_cx_upgrades_active などの統計によって追跡されます。

### H2ホップの取り扱い

Envoyは、一様な H2 メッシュを好む展開のために H2 ストリームを介した WebSocket のトンネリングをサポートします。これにより、たとえば、次の形式の配置が可能になります。

[Client] - HTTP / 1.1 - Front Envoy - HTTP / 2 - サイドカーEnvoy - H1 - App

この場合、クライアントがたとえば WebSocket を使用している場合、Websocket が機能的には上流のサーバーに到達するようにします。つまり、HTTP/2 ホップを通過する必要があります。

これは、拡張 CONNECT サポートを介して行われます。 WebSocket 要求は、元のアップグレードを示すプロトコルヘッダーを使用して HTTP/2 CONNECT ストリームに変換され、HTTP/2 ホップを通過し、HTTP/1 WebSocket アップグレードにダウングレードされます。これと同じ Upgrade-CONNECT-Upgrade 変換は、HTTP/1.1 メソッドが常に GET であると想定されているという文書化された欠陥とともに、すべての HTTP/2 ホップで実行されます。 WebSocket 以外のアップグレードでは有効な HTTP メソッド（ POST ）を使用でき、現在のアップグレード/ダウングレードメカニズムでは元のメソッドが削除され、最後の Envoy-Upstream ホップで Upgrade 要求が GET メソッドに変換されます。

H2 アップグレードパスは HTTP/1.1 に非常に厳密に準拠しているため、WebSocket のアップグレード要求または本文を含む応答を代理することはありません。
Envoy: gRPC

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## gRPC

gRPC は Google の RPC フレームワークです。基盤となるシリアル化/ IDL フォーマットとしてプロトコルバッファを使用します。トランスポート層では、要求/応答の多重化に HTTP/2 を使用します。 Envoyはトランスポート層とアプリケーション層の両方で gRPC を一流のサポートをしています。

- gRPC はリクエストステータスを伝えるために HTTP/2 トレーラを利用します。 Envoy は、HTTP/2 トレーラを正しくサポートする非常に少数の HTTP プロキシの1つであり、したがって gRPC 要求と応答を転送できる数少ないプロキシの1つです。
- 一部の言語用の gRPC ランタイムは比較的未熟です。 gRPC をより多くの言語に移行するのに役立つフィルタの概要については、以下を参照してください。
- gRPC-Web は、gRPC-Web クライアントが HTTP/1.1 経由で Envoy にリクエストを送信し、gRPC サーバーにプロキシされることを可能にするフィルタによってサポートされています。現在開発中であり、gRPC ブリッジフィルタの後継となることが期待されています。
- gRPC-JSON トランスコーダは、RESTful JSON API クライアントが HTTP 経由で Envoy にリクエストを送信し、gRPC サービスにプロキシされることを可能にするフィルタによってサポートされています。

### gRPC ブリッジング

Envoy は2つの gRPC ブリッジをサポートしています。

- gRPC リクエストを HTTP/1.1 経由で Envoy に送信することを許可する grpc_http1_bridge フィルタ。その後、Envoy はターゲットサーバーへの転送のためにリクエストを HTTP/2 に変換します。応答は HTTP/1.1 に戻されます。インストール時に、ブリッジフィルタはグローバル HTTP 統計の標準配列に加えて RPC ごとの統計を収集します。
- grpc_http1_reverse_bridge フィルタ。これは、 gRPC リクエストが Envoy に送信され、アップストリームに送信されたときに HTTP/1.1 に変換されるようにします。その後、応答はダウンストリームに送信されたときに gRPC に変換されます。このフィルタはオプションで gRPC フレームヘッダを管理することもでき、アップストリームが gRPC を意識する必要がまったくないようにすることができます。

### gRPC サービス

データプレーンで gRPC をプロキシすることに加えて、Envoy はコントロールプレーン用に gRPC を使用します。そこで、管理サーバーからの設定の取得や、レート制限や承認チェックなどのためのフィルタでの設定が行われます。これらを gRPC サービスと呼びます。

gRPC サービスを指定するときは、Envoy gRPC クライアントまたは Google C ++ gRPC クライアントのどちらを使用するかを指定する必要があります。以下に、この選択におけるトレードオフについて説明します。

Envoy gRPC クライアントは、Envoy の HTTP/2 アップストリーム接続管理を利用する、gRPC の最小限のカスタム実装です。サービスは通常の Envoy クラスターとして指定され、タイムアウト、再試行、エンドポイント検出/ロードバランシング/フェイルオーバー/ロードレポート、回線遮断、ヘルスチェック、異常値検出が定期的に処理されます。それらは Envoy データプレーンと同じ接続プールメカニズムを共有します。同様に、クラスター統計は gRPC サービスに利用できます。クライアントは最小限であるため、OAuth2 や gRPC-LB ルックアサイドなどの高度な gRPC 機能は含まれていません。

Google C ++ gRPC クライアントは、https://github.com/grpc/grpc で Google が提供する gRPC の参照実装に基づいています。 Envoy gRPC クライアントにはない、高度な gRPC 機能を提供します。 Google C ++ gRPC クライアントは、Envoy のクラスタ管理とは無関係に、独自の負荷分散、再試行、タイムアウト、エンドポイント管理などを実行します。 Google C ++ gRPC クライアントは、カスタム認証プラグインもサポートしています。

Google C ++ gRPC クライアントの高度な機能が不要な場合は、ほとんどの場合 Envoy gRPC クライアントを使用することをお勧めします。これにより、設定と監視が簡単になります。 Envoy gRPC クライアントに必要な機能がない場合は、代わりに Google C ++ gRPC クライアントを使用してください。
Envoy: HTTP ルーティング

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## HTTP ルーティング

Envoy には、高度なルーティングタスクを実行するためにインストールできるHTTPルーターフィルタが含まれています。これは、エッジトラフィックの処理（従来のリバースプロキシ要求処理）と、サービスto Envoyメッシュ（通常は特定のアップストリームサービスクラスタに到達するためのホスト/認証HTTPヘッダーでのルーティングによる）の構築の両方に役立ちます。 Envoyにはフォワードプロキシとして設定する機能もあります。フォワードプロキシ設定では、メッシュクライアントは自分のhttpプロキシをEnvoyになるように適切に設定することで参加できます。上位レベルでは、ルータは着信HTTP要求を受け取り、それをアップストリームクラスタと照合し、アップストリームクラスタ内のホストに接続プールを取得して、その要求を転送します。ルータフィルタは次の機能をサポートします。

- ドメイン/権限を一連のルーティングルールにマッピングする仮想ホスト。
- プレフィックスと正確なパスマッチングルール（大文字と小文字の区別と大文字と小文字の区別なし）。正規表現とスラッグのマッチングは、現在サポートされていません。これは、ルーティングルールが互いに矛盾するかどうかをプログラムで判断するのが困難/不可能になるためです。このため、リバースプロキシレベルでの正規表現/スラッグルーティングはお勧めできませんが、将来的には需要に応じてサポートを追加する可能性があります。
- 仮想ホストレベルでのTLSリダイレクト
- ルートレベルでのパス/ホストリダイレクション
- ルートレベルでの直接（プロキシではない）HTTP応答。
- 明示的なホストの書き換え
- 選択したアップストリームホストのDNS名に基づく自動ホスト書き換え。
- 書き換えのプレフィックス。
- HTTPヘッダーまたはルート設定を介して指定された要求再試行。
- HTTPヘッダーまたはルート設定を介して指定された要求タイムアウト。
- ランタイム値を介したトラフィックのアップストリームクラスタ間のトラフィックシフト（トラフィックシフト/分割を参照）。
- ウェイト/パーセンテージベースのルーティングを使用した複数のアップストリームクラスタ間でのトラフィック分割（トラフィックシフト/分割を参照）。
- ルーティングルールに一致する任意のヘッダー
- 仮想クラスタの仕様仮想クラスタは仮想ホストレベルで指定され、標準のクラスタレベルの統計に加えて追加の統計を生成するためにEnvoyによって使用されます。仮想クラスタは正規表現照合を使用できます。
- 優先度ベースのルーティング
- ハッシュポリシーベースのルーティング
- 絶対URLは、非TLSフォワードプロキシでサポートされています。
    

### ルートテーブル

HTTP接続マネージャの設定は、設定されたすべてのHTTPフィルタによって使用されるルートテーブルを所有します。ルータフィルタはルートテーブルの主要なコンシューマですが、他のフィルタも、要求の最終的な宛先に基づいて決定を行いたい場合に備えてアクセス権を持ちます。たとえば、組み込みレート制限フィルタは、ルートテーブルを調べて、グローバルレート制限サービスをルートに基づいて呼び出す必要があるかどうかを判断します。接続マネージャは、その決定がランダム性を含む場合であっても（例えば、実行時構成ルートルールの場合）、ルートを取得するためのすべての呼び出しが特定の要求に対して安定していることを確認する。

### 再試行セマンティクス

Envoyでは、ルート設定とリクエストヘッダを介した特定のリクエストの両方で再試行を設定できます。以下の構成が可能です。

- 最大再試行回数：Envoyは何度でも再試行します。各再試行の間に指数バックオフアルゴリズムが使用されます。さらに、すべての再試行は全体の要求タイムアウト内に含まれています。これにより、多数の再試行による長い要求時間が回避されます。
- 条件の再試行：アプリケーションの要件に応じて、Envoyはさまざまな種類の条件で再試行できます。たとえば、ネットワーク障害、すべての5xx応答コード、べき等4xx応答コードなど
- ホスト選択の再試行プラグイン：再試行のためにホストを選択するときに、ホスト選択のロジックに追加のロジックを適用するようにEnvoyを設定できます。再試行ホスト述語を指定することは、特定のホストが選択されたとき（例えば、既に試みられたホストが選択されたとき）にホスト選択を再試行することを可能にする。

x-envoy-overloadedの内容によっては、再試行が無効になることがあります。

### 優先ルーティング

Envoyはルートレベルで優先ルーティングをサポートしています。現在の優先度の実装では、優先度ごとに異なる接続プールと回線遮断設定が使用されます。これは、HTTP / 2要求でも、2つの物理接続が上流のホストに使用されることを意味します。将来的には、Envoyは単一の接続で真のHTTP / 2優先度をサポートするでしょう。

現在サポートされている優先順位は、デフォルトと高いです。

### 直接の回答

Envoyは「直接」回答の送信をサポートしています。これらは事前設定されたHTTP応答で、上流のサーバーへのプロキシを必要としません。

ルートで直接応答を指定する方法は2つあります。

- direct_responseフィールドを設定してください。これはすべてのHTTPレスポンスステータスに有効です。
- リダイレクトフィールドを設定します。これはリダイレクト応答ステータスに対してのみ機能しますが、Locationヘッダーの設定を単純化します。

直接応答にはHTTPステータスコードとオプションの本文があります。 Route設定では、レスポンスボディをインラインで指定するか、ボディを含むファイルのパス名を指定できます。 Route設定がファイルパス名を指定している場合、Envoyは設定のロード時にファイルを読み込み、内容をキャッシュします。

#### 注意

応答本体が指定されている場合、それがインラインで提供されているかファイルで提供されているかにかかわらず、サイズは4KB以下でなければなりません。 Envoyは現在、本文全体をメモリに保持しているため、4KBの制限は、プロキシのメモリ使用量が大きくなり過ぎないようにするためのものです。

response_headers_to_addがルートまたはそれを含む仮想ホストに設定されている場合、Envoyは指定されたヘッダーを直接HTTP応答に含めます。
Envoy: 動的状態

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


### 動的状態

動的状態は、ネットワーク接続ごとまたは HTTP ストリームごとに生成されます。動的状態は、必要に応じて状態を生成するフィルタによって変更可能にすることができます。

Envoy::Network::Connection and Envoy::Http::Filter は、現在の TCP 接続および HTTP ストリーム（すなわち、HTTP 要求／応答対）についての情報をそれぞれ含む StreamInfo オブジェクトを提供する。 StreamInfo は、クラス定義（例えば、HTTP プロトコル、要求されたサーバ名など）の一部として1組の固定属性を含む。さらに、型指定されたオブジェクトをマップに格納する機能も提供します（map <string、FilterState :: Object>）。フィルタごとに保存される状態は、追記型（不変）または追記型（不変）のいずれかです。
Envoy: 静的状態

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。




## 静的状態
Envoyは、フィルタ、フィルタ間、および他のコアサブシステムへの設定、メタデータ、および要求/接続ごとの状態の転送について、次のようなメカニズムを提供します（アクセスログなど）。

静的状態は、構成ロード時に（例えば、xDS を介して）指定された不変状態である。静的状態には3つのカテゴリがあります。

### メタデータ

Envoyの設定のいくつかの部分（リスナー、ルート、クラスタなど）には、任意のキーと値のペアをエンコードできるメタデータが含まれています。一般的なパターンは、キーとしてリバース DNS 形式のフィルタ名を使用し、値にフィルタ固有の設定メタデータをエンコードすることです。このメタデータは不変であり、すべての要求/接続にわたって共有されます。このような設定メタデータは通常、ブートストラップ時または xDS の一部として提供されます。たとえば、HTTP ルートの加重クラスタは、加重クラスタに対応するエンドポイントのラベルを示すためにメタデータを使用します。別の例では、サブセットロードバランサは、重み付けされたクラスタに対応するルートエントリからのメタデータを使用して、クラスタ内の適切なエンドポイントを選択します。

### 型付きメタデータ

メタデータ自体は型指定されていません。メタデータを処理する前に、呼び出し側は通常、それを型付きクラスオブジェクトに変換します。変換コストは、（例えば、各要求ストリームまたは接続に対して）繰り返し実行されると無視できなくなる。型付きメタデータは、フィルタが特定のキーに対して1回限りの変換ロジックを登録できるようにすることで、この問題を解決します。 （ xDS を介した）受信設定メタデータは、設定ロード時にクラスオブジェクトに変換されます。フィルタは実行時に（要求または接続ごとに）型指定されたメタデータを取得できるため、要求/接続処理中に ProtobufWkt :: Struct から何らかの内部オブジェクトに繰り返し変換するフィルタが不要になります。

たとえば、ClusterInfo のキー xxx.service.policy を持つ不透明なメタデータの上にコンビニエンスラッパークラスを持つことを望むフィルタは、ClusterTypedMetadataFactory から継承するファクトリ ServicePolicyFactory を登録できます。ファクトリは ProtobufWkt :: Struct を ServicePolicy クラスのインスタンスに変換します（ FilterState :: Object から継承）。クラスタが作成されると、関連付けられた ServicePolicy インスタンスが作成されキャッシュされます。型付きメタデータはメタデータの新しいソースではないことに注意してください。構成の一部として指定されているメタデータから取得されます。

### HTTP ルート別フィルタの設定

HTTP ルートでは、per_filter_config を使用すると、HTTP フィルタはすべての仮想ホストに共通のグローバルフィルタ設定に加えて、仮想ホスト/ルート固有の設定を持つことができます。この設定は変換され、ルートテーブルに組み込まれます。ルート固有のフィルタ設定をグローバル設定または機能拡張の代わりとして扱うのは、HTTP フィルタの実装次第です。たとえば、HTTP 障害フィルタはこの手法を使用して、ルートごとの障害構成を提供します。

per_filter_configは マップ<文字列、ProtobufWkt :: Struct>です。接続マネージャはこのマップを繰り返し処理し、フィルタファクトリインタフェース createRouteSpecificFilterConfig を呼び出して構造体の値を解析/検証し、それをルート自体に格納されている型付きクラスオブジェクトに変換します。 HTTP フィルタは、リクエスト処理中にルート固有のフィルタ設定を問い合わせることができます。
AWS RDSで設定を変更したらAccess denied  (using password: YES)でmysql ログインできなくなった

RDS MySQLの設定を変更してEC2からmysqlログインしようとしたら、、、

```
ERROR 1045 (28000): Access denied for user 'USERNAME'@'IP ADDRESS' (using password: YES)
```

地味に1.5時間くらい時間取られたので、メモ。

#解決
以下のパスワードボックスが空になってしまったまま変更を適用してしまっていた。。これだけか。。
ここにパスワードを入れ直して再度変更を適用したら自分の場合ログインできるようになりました。

![スクリーンショット 2019-06-04 9.27.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/149952/671531b0-a36c-7b45-be85-98330253a1cf.png)
【Ruby】attr_accessor(attr_reader, attr_writer)について調べた

## attr_accssorとは

> attr_accessorメソッドは、クラスやモジュールにインスタンス変数を読み書きするためのアクセサメソッドを定義します。引数には、インスタンス変数名をシンボルか文字列で指定します（複数指定できます）。戻り値はnilです。

引用元 https://ref.xaio.jp/ruby/classes/module/attr_accessor

## コード例

```ruby

class Cigarettes
  attr_accessor :price
  
  def initialize(price)
    @price = price
  end
end
 
# インスタンス生成
cigarettes = Cigarettes.new(450)

p cigarettes.price
# => 450
cigarettes.price = 470
p cigarettes.price
# => 470

```

`attr_accessor`で、`getter`と`setter`をいっぺんに定義するイメージ。
ちなみに、`attr_accessor`を用いない場合は、下記のようにする必要がある。

```ruby

class Cigarettes
  def price
    @price
  end
  def price=(val)
    @price = val
  end
  （後略）

```

`def price=(val)`は初めて見たとき戸惑ってしまったが、

```ruby

cigarettes.price = 470
```

のように、`price`への代入式を書いた時に呼び出される(`setter`)。

## attr_readerとattr_writer
関連して、`attr_reader`と`attr_writer`も存在する。

`attr_reader`はインスタンス変数の読み出し専用アクセサを定義できる。

```ruby

class Cigarettes
  attr_reader :price
  
  def initialize(price)
    @price = price
  end
end
 
# インスタンス生成
cigarettes = Cigarettes.new(450)

p cigarettes.price
# => 450
cigarettes.price = 470
# => `<main>': undefined method `price=' for #<Cigarettes:0x00007ff50b048910 @price=480> (NoMethodError)


```

インスタンス生成後に、インスタンス変数の値を変えたくない場合に使えそう。

`attr_writer`は、インスタンス変数の書き込み専用アクセサを定義する。

```ruby

class Cigarettes
  attr_writer :price
  
  def initialize(price)
    @price = price
  end
end
 
# インスタンス生成
cigarettes = Cigarettes.new(450)

p cigarettes.price
=> undefined method `price' for #<Cigarettes:0x00007f9685054420 @price=450> (NoMethodError)

```

`atter_reader`と逆で、インスタンス生成時にインスタンス変数の値を設定した後は、読み出すことはできない。
Envoy: HTTP フィルタ

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## HTTP フィルタ

ネットワークレベルのフィルタスタックと同様に、Envoy はコネクションマネージャ内で HTTP レベルのフィルタスタックをサポートしています。基礎となる物理プロトコル（HTTP/1.1、HTTP/2など）や多重化機能に関する知識がなくても、HTTP レベルのメッセージを処理するフィルタを作成できます。 HTTP レベルフィルタには3つの種類があります。

- デコーダ
  コネクションマネージャがリクエストストリームの一部（ヘッダ、ボディ、およびトレーラ）をデコードしているときに、デコーダフィルタが呼び出されます。
- エンコーダ
  接続マネージャが応答ストリームの一部（ヘッダ、ボディ、およびトレーラ）をエンコードしようとしているときに、エンコーダフィルタが呼び出されます。
- Decoder/Encoder
  Decoder/Encoder フィルタは、コネクションマネージャがリクエストストリームの一部をデコードしているときと、コネクションマネージャがレスポンスストリームの一部をエンコードしようとしているときの両方で呼び出されます。

HTTP レベルフィルタ用のAPIを使用すると、基礎となるプロトコルに関する知識がなくてもフィルタを操作できます。ネットワークレベルのフィルタと同様に、HTTP フィルタは停止して後続のフィルタへの繰り返しを継続できます。これにより、ヘルスチェック処理、レート制限サービスの呼び出し、バッファリング、ルーティング、DynamoDB などのアプリケーショントラフィックの統計情報の生成など、より複雑なシナリオが可能になります。HTTP レベルフィルタは、コンテキスト内で状態（静的および動的）を共有できます。単一の要求ストリーム詳細については、フィルタ間のデータ共有を参照してください。 Envoy には、このアーキテクチャーの概要および構成の参照で文書化されているいくつかの HTTP レベルのフィルターが既に含まれています。
Envoy: ネットワーク（L3/L4）フィルタ

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## ネットワーク（L3/L4）フィルタ

リスナーのセクションで説明したように、ネットワークレベル（L3 / L4）フィルターはEnvoyの接続処理の中核を形成します。フィルタAPIを使用すると、さまざまなフィルタのセットを混在させてマッチングし、特定のリスナーに添付することができます。ネットワークフィルタには3つの異なる種類があります。

- 読み取り：読み取りフィルタは、Envoy がダウンストリーム接続からデータを受信したときに呼び出されます。
- 書き込み：書き込みフィルタは、Envoy がダウンストリーム接続にデータを送信しようとしているときに呼び出されます。
- 読み取り/書き込み：読み取り/書き込みフィルタは、Envoy がダウンストリーム接続からデータを受信したときと、ダウンストリーム接続にデータを送信しようとしているときの両方で呼び出されます。

ネットワークレベルフィルタのための API は、最終的に生のバイトおよび少数の接続イベント（例えば、TLS ハンドシェイク完了、接続のローカルまたはリモート切断など）で動作するので比較的単純である。チェーン内のフィルタは停止し、その後さらにフィルタへの反復を続けることができます。これにより、レート制限サービスなどの呼び出しなど、より複雑なシナリオが可能になります。ネットワークレベルのフィルタでは、単一のダウンストリーム接続のコンテキスト内で状態（静的および動的）を共有できます。詳細については、フィルタ間のデータ共有を参照してください。 Envoyには、このアーキテクチャの概要および構成の参照で文書化されているいくつかのネットワークレベルのフィルタが既に含まれています。
Envoy: リスナフィルタ

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## リスナフィルタ

リスナのセクションで説明したように、リスナフィルターは接続メタデータを操作するために使用できます。リスナフィルタの主な目的は、Envoyのコア機能を変更する必要がないことでシステム統合機能をさらに追加しやすくすること、およびそのような複数の機能間の対話をより明確にすることです。

最終的にこれらのフィルタは新しく受け入れられたソケットで動作するので、リスナフィルタのAPIは比較的単純です。チェーン内のフィルタは停止し、その後さらにフィルタへの反復を続けることができます。これにより、レート制限サービスの呼び出しなど、より複雑なシナリオが可能になります。Envoyには、このアーキテクチャの概要および構成の参照で説明されているリスナフィルタが既にいくつか含まれています。
Envoy: スレッドモデル

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。

## スレッドモデル

Envoyは、マルチスレッドアーキテクチャの単一プロセスを使用しています。 単一のマスタースレッドがさまざまな散発的な調整タスクを制御し、いくつかのワーカースレッドがリスニング、フィルタリング、および転送を実行します。 接続がリスナーに受け入れられると、その接続の残りの有効期間は単一のワーカースレッドに割り当てられます。 これにより、Envoyの大部分は、ワーカースレッド間でのより複雑なコード処理協調を伴って、大部分がシングルスレッド（恥ずかしいほど並列）になることができます。 一般的に、Envoyは100％ノンブロッキングになるように書かれています。ほとんどのワークロードでは、ワーカースレッドの数をマシンのハードウェアスレッドの数と等しくなるように設定することをお勧めします。
Envoy: 用語

# tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントは[こちらのディレクトリ以下](https://github.com/envoyproxy/envoy/tree/master/docs)にあります（ライセンス：[Apache License 2.0](https://github.com/envoyproxy/envoy/blob/master/LICENSE), [NOTICE](https://github.com/envoyproxy/envoy/blob/master/NOTICE)）。


## 用語

メインのアーキテクチャードキュメントに入る前に、いくつか定義をしておきます。定義の中には、業界内で少し論議を呼んでいるものもありますが、それが Envoy 自身がドキュメントおよびコードベース全体でそれらをどう扱っているということです。まあ、そんなものですよね。

- ホスト
  ネットワーク通信が可能なエンティティ（携帯電話、サーバーなどのアプリケーション）。このドキュメントでは、ホストは論理ネットワークアプリケーションです。ハードウェアの物理的な部分では、それぞれを個別にアドレス指定できる限り、複数のホストを実行することができます。

- ダウンストリーム
  ダウンストリームホストはEnvoyに接続し、要求を送信し、そして応答を受信します。

- アップストリーム
  アップストリームホストはEnvoyから接続と要求を受信し、応答を返します。

- リスナ
  リスナは、下流のクライアントによって接続することができる名前付きネットワークロケーション（例えば、ポート、ユニックスドメインソケットなど）である。 Envoyは下流のホストが接続する1つ以上のリスナーを公開します。

- クラスタ
  クラスタとは、Envoy が接続する論理的に類似したアップストリームホストのグループです。 Envoy はサービスディスカバリを通じてクラスタのメンバーを発見します。これはオプションで、アクティブヘルスチェックを介してクラスターメンバーのヘルスを決定します。 Envoyがリクエストをルーティングするクラスタメンバーは、負荷分散ポリシーによって決定されます。

- メッシュ
  一貫したネットワークトポロジを提供するように調整するホストのグループ。このドキュメントでは、「Envoyメッシュ」とは、さまざまなサービスやアプリケーションプラットフォームで構成される分散システム用のメッセージパッシングサブストレートを形成するEnvoyプロキシのグループです。

- ランタイム構成
  Envoyと一緒に配置された帯域外リアルタイム構成システム。 Envoyを再起動したり、プライマリ設定を変更したりすることなく、動作に影響を与える設定を変更することができます。
プロキシ環境下でadd-apt-repositoryを通す方法

# Vim8.0を入れたい

ubuntuでvimを入れる際は基本的には

```sh

$ sudo apt install vim
```
としてインストールすると思うのですが、これだとVim7.4になってしまいます。
ただ、私はvim8.0を使いたいので

```sh

$ sudo add-apt-repository -y ppa:jonathonf/vim
```
で非公式リポジトリを追加してから、インストールしています。
こうするとVim8.0をaptでインストールできるのはvimmerには有名な話。

# 会社でadd-apt-repositoryできない問題

ここで厄介なのが会社等のプロキシ環境下でadd-apt-repositoryをするとERRORで引っかかってしまい、リポジトリを追加できません。

```sh

$ sudo add-apt-repository -y ppa:jonathonf/vim
Cannot add PPA: 'ppa:~jonathonf/ubuntu/vim'.
ERROR: '~jonathonf' user or team does not exist.
```
このERRORが厄介なのがエラーメッセージ読んでも原因がさっぱりわからないところなんですよね。
そのため会社ではVim7.4を使ったり、Vim8.0をコンパイルしたりとごまかしながらVim生活を送っていました。

# 解決策

新しいPCをセットアップするたびに調べては挫折してを幾度も繰り返しているある時、急に原因が判明しました。
知ってしまえばとても単純な話だったのですが、sudoではユーザーがbash等で設定している環境変数が引き継がれないため、プロキシを突破できていないだけでした。

ということでsudoで環境変数を引き継がせるための引数Eを指定すればいいだけの簡単なお仕事でした。

```sh

$ sudo -E add-apt-repository -y ppa:jonathonf/vim
```

# 参考にさせて頂いたサイト

[改めてsudoについて調べてみた](https://qiita.com/genreh/items/98f4a7ff5d1443e1e5cd)
学習を兼ねてPHPでポートフォリオを作成 ~リスト共有サービス SHARE-LIST~

# はじめに
PHPの基礎の学習知識の定着を兼ねてポートフォリオを作成したのでサービスの概要、使用技術、機能、作成方法、課題を説明します。

# 目的
PHPを使用したWebサービスをフルスクラッチで開発し、下記の項目について理解を深める。
 
- セッション 
- GET送信とPOST送信
- 条件分岐(if文、switch文)と繰り返し処理(foreach文)などの基本構文
- DB関連(DB接続、SQL文) 
- DBデータの編集、画面への出力

# 使用技術について
- 言語
    - PHP
    - HTML
    - CSS
    - Javascript
- DBMS
    - MySQL
- フレームワーク
    - なし
- サーバー
    - Xサーバー
- ローカル環境
    - MAMP

# ポートフォリオ概要
リストを投稿して、共有するWEBサービス
URL: https://sharelist.dekitablog.com/

テストユーザー
Email: testuser@sample.com
Pass: 123456

# ポートフォリオ機能

- ログイン関連
    - ユーザー登録
    - ログイン
    - ログアウト
    - 退会
- プロフィール関連
    - プロフィール登録
    - プロフィール編集
- パスワード関連
    - パスワード変更
    - パスワードリマインダー
- コンテンツ関連
    - コンテンツ登録
    - コンテンツ一覧表示
    - コンテンツ詳細表示
    - コンテンツ検索
    - コメント
    - お気に入り登録

# 各機能サンプルGIF
ログイン関連
![na0us-3sz8d.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/68f74e08-b78f-43c6-7c54-a315a243c503.gif)
ユーザー登録 → ログアウト → ログイン → 退会 → ログインNG

![バリデーションチェック.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/ece32b91-3f9a-0456-c4f6-b36594cdea30.gif)
バリデーションチェック
空欄チェック → Email形式チェック + 最小文字列チェック → パス一致チェック → 重複チェック

プロフィール関連
![プロフィール関連.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/b6f44aee-76d3-667a-0f10-381afc0f6b2b.gif)
名前登録 + プロフィール画像登録 → プロフィール画像変更

コンテンツ関連
![リスト投稿.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/7033b252-d9ad-87c2-5d1e-53263f1c5d59.gif)
リストの投稿

![コンテンツ投稿-お気に入り.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/d2385d74-1806-8ce8-a97f-3a9418f4f78f.gif)
ページネーション → 詳細表示 → お気に入り登録

![カテゴリ検索-コメント.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/04032452-dbc0-b98d-a536-0ce1f865983c.gif)
カテゴリ検索 → コメント

# 作成手順
1.機能の洗い出し

2.ワイヤーフレーム作成 
![IMG_0510.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329852/39475264-48dd-2370-757c-927160b32842.jpeg)
iPadのVectornatorにて各ページワイヤーフレームを作成し、それぞれのページの関係を図にする。

3.テーブル設計

4.DB作成

5.画面モック作成
HTMLとCSSで静的なページを作成

6.各機能実装
PHPで各ページに機能を実装して動的なページを作成

7.各機能のテスト

8.デプロイ

おおまかな流れは上記の通りですが、工程は行ったり来たりして調整してます。

# 工夫したところ
Gitを使用してのバージョン管理
issueに不具合を挙げる
ブランチを切って修正を行う

# 課題
レスポンシブ対応
コンテンツ(リスト)数を動的に変更(現在は5個で固定)
コンテンツの編集・削除
カテゴリーの登録、変更、削除

# その他
GitHub: https://github.com/xxx-kohe-xxx
ツイッター: https://twitter.com/kohe_dekita
自動販売機を作ってみよう part5 - 設計からMySQL workbenchでDB作成まで

#間が空きました
part2-4まですっとばしてます。まとめられてません。
でも続きを書きます。書かないと覚えないので。

#やるしかねえ
デザイナーからエンジニアにジョブチェンジというかアビリティが加わるみたいな話が具体性を帯びてきた。
というわけでやっていきます

##今日やること

- 画面設計
- class設計
- DB設計

目標：6/20までに本稿の自動販売機のgithubリポジトリを作ること
なのでペースアップしていかないと間に合わねえぞ！頑張れ俺！

###手順1 画面設計、シロ！

- 画面の種類
- 画面の名前
- 画面の機能
を洗い出して設計を書いていきましょう

画面の種類

- topページ (index)
- 所持金設定
- 所持金確認画面
- 料金投入
- 商品選択
- 商品排出
- お金返却

以上7ページを設計する。

画面設計で決めることは
- 画面の名前=ページのURL
- 画面の機能(WFほどではないが、項目とボタン、フォームなど、ページに置くべき機能を並べる
- 画面のリンク(遷移先)(矢印で遷移を示す)(瞬足)(コーナーで差をつけろ)

今回はcacooを使用した。(cacoo、リアルタイムで他の人と画面共有できるの楽しい)
できた画面はこちら
![画面設計.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318674/2c3a8643-f219-f0fb-1f2b-7bd258c497b6.png)


画面ができたら、それを元にMySQL workbenchでDB設計する。
(30分で支度しな！！と言われたが時間ぶっちぎりオーバー。一時間くらいかかった。)

#### まずぶつかった壁
MySQLの使い方覚えられてない…
いろいろ使い方引っ張り出しながら設計した

#### 画面設計とDB設計は違う！
私は画面で出した項目=DBの項目、と勘違いしてしまい、DB設計を2周するハメになった。
ので、一旦、必要そうな項目を各ページからリストアップしてみた。

##### 所持金設定
- 所持金
- 足す金額
- 投入ボタン

##### 所持料金確認画面
- 所持金を〇〇に設定します(テキスト表示)
- 〇〇(金額足した後の所持金。結果)
- 確認ボタン

##### 料金投入ページ
- 所持金
- 投入する金額
- 投入ボタン

##### 商品選択ページ
- 投入額
- 所持金
- 商品(複数)
 - 商品名
 - 価格
 - 温度種別
 - 包装種別
 - 在庫有りなし表示
- 商品選択ボタン
- お金返却ボタン

(商品自体をページの機能からテーブル分けると楽になるのでは、
と、この辺からテーブル設計の概念が修正でき始めた気がする)

##### 商品排出ページ
- 購入した商品名
- 商品名
- 価格
- 包装種別
- 温度種別
- 個数
- トップに戻るボタン

##### お金返却ページ
- 返却金額
- 所持金
- トップに戻るボタン

#### トップページ
- 購入開始ボタン
- 購入済み商品一覧(複数)
　- 所持商品名
　- 飲むボタン/飲んだ表示

#### できあがりがこちら!
[スクリーンショット 2019-06-04 8.40.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318674/3115d59a-b896-101d-e725-0ba0b5de7620.png)

なにもかも合ってない！！！
時間切れで1:1とか1:nとかリレーションさせるところまで到達できなかったです
しかもめちゃくちゃな配置。
- 画面設計を先にやって、その画面設計と同じ配置でつくってしまった。
- URL=DB名ではないということを知った。


##一旦ここまで！
次回は答え合わせと、ER図の修正をやってみたいと思います。
TravisCIを使用して、タグ付きコミットのバージョン番号を付けたPythonパッケージをPyPIに自動的にリリースする

この記事では、TravisCIを使用して、タグ付きコミットのバージョン番号を付けたPythonパッケージをPyPIに自動的にリリースする方法について紹介します。パッケージのバージョンはコミットのタグによって自動的に決定されるため、`setup.py`のパッケージのバージョンを書き換える手間を省くことができます。

必要なものは以下の通りです。

* pythonパッケージを含むGitHubリポジトリ
* Travisのコマンドラインツール
* PyPIアカウント

# 設定ファイルを用意する

まず、Travis CIに何をすべきかを指示するために、リポジトリにTravisの設定ファイル（`.travis.yml`）を追加します。以下では、リポジトリをPython 3.6でビルドし、タグ付きコミットでのみデプロイするように設定します。`user`にはPyPIのユーザ名を設定しましょう。

```yaml
language: python

python:
  - '3.6'

script: true

deploy:
  provider: pypi
  user: "Your username"
  on:
    tags: true
```


# PyPIのパスワードを暗号化して設定ファイルに含める

次に、PyPIのパスワードを暗号化して設定ファイルに追加します。そのためには、Travisのコマンドラインツールを使うことができます。インストールしていない場合は、<https://github.com/travis-ci/travis.rb>を参考にしてインストールしてください。

まず、設定ファイルを置いてあるディレクトリに移動します。その後、次のコマンドを実行します。`your-password-here`はPyPIのパスワードに置き換えてください。

```bash
travis encrypt your-password-here --add deploy.password
```

実行後、暗号化されたパスワードが設定ファイルに含まれていることを確認できます。

```yaml
language: python

python:
  - '3.6'

script: true

deploy:
  provider: pypi
  user: "Your username"
  password:
    secure: "Your encrypted password"
  on:
    tags: true
```

# タグ付きコミットから自動的にパッケージバージョンを設定

最後に、タグ付けされたコミットから自動的にパッケージのバージョンを設定します。こうすることで、パッケージのバージョンを`setup.py`にハードコーディングする必要がなくなります。

パッケージのバージョンをタグから自動的に設定するためには`setuptools_scm`を使うことができます。まずは、以下のようにして`setuptools_scm`をインストールします。

```bash
pip install setuptools-scm
```

次に、`setup.py`を以下のように変更します。こうすることで、パッケージのバージョンを自動的にタグのバージョンから取得することができます。

```python
from setuptools import setup
setup(
    ...,
    use_scm_version=True,
    setup_requires=['setuptools_scm'],
    ...,
)
```

これで終わりです。

あとはタグを付けることで、パッケージを自動的にPyPIにリリースすることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/77079/ebe31e81-429b-528b-804a-c155c6f64a26.png)

以下のリポジトリに設定を書いてあるので参考にしてください。

* [chakki-works/seqeval](https://github.com/chakki-works/seqeval)
plunkerで真理値表 その4

#概要

plunkerで真理値表やってみた。
全加算器をトグルスイッチとLEDで実装してみた。

#写真

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/9dfad9dd-b6c7-8ca7-42f3-c790b7b40cea.png)

#成果物

https://embed.plnkr.co/tSr6tAENI1HYMDpxo3g1/

以上。
UiPath Go!メモ

UiPath Go! 使い方解説
https://mag.sweeep.ai/rpa/uipathgo/

しかしWebサイトに登録しなくても、パッケージ管理からインストールできそう。
(Community Edition限定か？)
![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/424975/c017b1c1-1695-aaea-45f4-c46729a5cec0.png)


ArchiveLib
https://go.uipath.com/component/archivelib
zipファイルを作成・解凍できる。

Get Column Letter
https://go.uipath.com/component/csm-activities
DataTableと列名を渡すと、Excel上の列番号を返す。
読取開始位置がB2とかでも正常に動作するんだろうか？

Task Scheduler
https://go.uipath.com/component/task-scheduler-using-windows-task-scheduler
タスクスケジューラの登録/削除が手軽に行える。
Attended Robotもタスクに含められる(ライセンス的にはどうなのか？？)

Excel Extension Activities
https://go.uipath.com/component/excel-extension-activities
Excelの操作詰め合わせ
Unity：360度写真、全天球での使い方（VR、360度画像）


# はじめに

*こんにちは、のんびりエンジニアのたっつーです。*
*[ブログ](https://www.fast-system.jp/)を運営しているのでよろしければ見てください。*

今回は、360度写真（360度パノラマ画像）を Unity の全天球として使う方法をご紹介させていただきます。
高解像度のVR機器（VIVE、Oculusなど）でも 4K、8K画像でみると少し荒がでますが現実で撮影した画像がそのままUnity内に取り込めて楽に使えるのでおススメです。

# 360°写真とは？

周囲360°の風景を１枚の四角画像に収めた写真になります。

以下のような 左右それぞれ歪んだ画像 を見たことがある人も多いかと思います、この画像は***エクイレクタングラー形式（ 水平360度、頭上から足元までの垂直180度 ）***で作成されたものです。

![f0da90d31fd1127a6b7fae76eae59bb3_2-500x250.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/1a5ec5a1-7f24-eb25-d678-e50eff8c6127.jpeg)

ドームマスター形式（ 水平360度、地平線から頭上までの垂直90度 ）のフォーマットもありますが、今回は エクイレクタングラー 形式を利用して Unity に取り込んでいきたいと思います。

RICOH HETAなどで撮影した写真をお持ちの方はそちらをご利用して、写真を撮影などして取り込んでください。
持っていない方は「エクイレクタングラー」「 360 panorama image 」などで検索して使用してみましょう。（著作権にはご注意ください）

# Unity での使い方

## 全天球のモデルを配置

全天球のモデルを提供してくれている方がいらっしゃるのでありがたいですね！
[Sphere100.fbx](https://t.co/kJSLDQuMWh) を ダウンロードしてください。

次に、ダウンロードしたファイルを ***Projectビューにドラッグアンドドロップ***で取り込んでください。
![image-80.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/0ff89169-e1fa-c786-055d-4ea35fd0929d.png)

正常に取り込まれると以下のような感じになります。
![image-81.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/70ea8cd4-463e-87b8-3c0d-b6fba004e2bb.png)

さっそく使ってみましょう。
Sphere100 を ***Hierarchyウィンドウに ドラッグアンドドロッド*** で実際にモデルを確認してみましょう。
![image-82.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/4a99ac72-b8d6-6e85-3199-08ae32f7b93c.png)

取り込みが完了するとこんな感じになります。
（わかりやすいようにワイヤーフレームで表示しています）
![image-83.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/b877ff05-40c5-9e12-7000-3b4bd14d0b73.png)

## 360度写真を全天球に張り付ける

さきほど探した画像を Unity に取り込みます。
***Projectビューに写真をドラッグアンドドロップ***します。
![image-84.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/58413d3d-e470-1164-6933-12f64355c58e.png)

次に、***「Sphere100」を選択した状態で、画像を何もない部分にドラッグアンドドロップ***します。
![image-85.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/fbd0ab18-8a75-d73a-bf3a-24fab180656d.png)

そうすると新しいマテリアルが作成されて、360度画像が設定されます。
![image-86.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/ce42a098-05b8-a87c-92b4-3eaae920dd37.png)

お疲れ様です、これで360度画像が使えるようになりました
簡単ですね！！
![unity-360-2.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/227880/fbd7b2b6-7e26-b4fc-738b-4cbcd074f867.gif)


# 終わりに

*よければ ブログ「[Unity+AssetStoreおすすめ情報](https://www.fast-system.jp/)」の方にも色々記載しているのでぜひご参照いただければと思います。*
MACの法則について

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/257568/eecbecde-7325-b4c0-2729-27c36482fb34.png)

こちらの本を読んで個人的にも徹底したいと感じたのでまとめ

## 目的
効率的なアプローチするため

## MACの法則とは
目標設計において重要な要素の3つの頭文字を取ったもの

- Measurable(メジャラブル)
- Actionable(アクショナブル)
- Competent(コンピテント)

### Measurable
測定可能性

定性的ではなく定量的な数字で測れる目標や指標にすること

例)
- ×：プログラミングスピードを上げる。がむしゃらにコーディングをする
- ○：プログラミングを1日1回する。コミットを計測する

### Actionable
行動可能性

目標達成までのプロセスを具体化すること

例)
プログラミングを1日1回する

- 習慣化を考える
- 実装に落とし込む際に必要な知識、ノウハウを収集する
- 実装題材を素早く決断するための情報を収集する
- サンプルを元にプログラミングする
- 自分の作りたいものをプログラミングする

### Competent
適格性

目標が自分の価値観に合っていること

例)
要求〜プロトタイプをすぐできるようなスキルを身につけたい

->プログラミングを1日1回することは限られた時間で実装までの判断を繰り返し行うので機能する


## 書籍情報
北村拓也. 独学で身につけるためのプログラミング学習術
https://amzn.to/2Vh6jEZ

## 雑感
OKRとも考えの切り分け方は近そう

頭の中だけで考えているだけだと、推測ベースになりがちで正確性も実現性も低いので、常に測定可能で可視化したものを思考や判断の材料として揃えるアプローチをする
RailsアプリでActiveStorage + AWS S3を使ってみよう！

#Railsアプリでの画像アップロードに何を使ってますか？

Railsアプリでの画像アップロードには何を使ってますか？
carrierwaveでモデルと関連付けを行って、ファイルはpubic/imagesに保存していますか？
私もRails学習用のアプリ開発にcarrierwaveを使ってます。使いやすくて良いですよね。
しかしRails5.2からはActiveStorageという備え付けの
ストレージ管理機能が追加されているらしいです。

せっかくなので今回は、ActiveStorageへと移行し
外部ストレージとしてAWS S3を使用する構成に替えて行きたいと思います。


## Railsガイドわかりやすいです！

### [Active Storage の概要](https://railsguides.jp/active_storage_overview.html)

こちらのRAILSガイドの説明が分かりやすいです。
ですが細かいところで自分の環境と差異があったりしたので
そこらへんを含めながらメモを残します。
ではやっていきましょーー

# ActiveStorage + S3 導入手順 
## AWSのセットアップ
AWSに登録の部分は省略します。
登録していない方は中々面倒な作業ですがAWSに登録してください。

流れとしては
・S3バケットを作成・設定
・IAMユーザーを作成してS3バケットを使えるように設定
・IAMユーザーの認証情報をRailsで使用する
という３ステップです。

###S3バケットの作成

S3サービスへ移動して、「バケットの作成」をします。
バケットを作るとはストレージのフォルダを作るというイメージです。
特にデフォルトのまま変更なく作成すれば大丈夫です。

###IAMユーザーの作成

AWSではIAMという機能を用いて各機能へのアクセス権限を制御します。
IAMで与えた権限の超えた動作を行うことができないので
もしもkeyが流出したとしても最小限の被害に抑えることができます。

IAMサービスのページに移動したら
「ユーザー」→「ユーザー作成」→「名前を自由に入力して、プログラムによるアクセスにチェック」
「既存のポリシーをアタッチ」→「S3FullAccessを検索してチェック」
で他はデフォルトのまま作成完了で大丈夫かと思います。

これでS3に自由にアクセスできるユーザーが作成されました。

ここで示される
**アクセスキー ID**
**シークレットアクセスキー**
を控えておきましょう。（CSVファイルをダウンロードすれば簡単です。）

これらをRailsアプリで使用します。


**※今回は開発環境用にS3FullAccessポリシーをアタッチしていますが本番環境では
権限を制限しておいたほうが良いと思います。**（**[こちらの記事](https://qiita.com/daichi41/items/a045ac60fa087a9763ba)**で解説しています。）

## AWS S３の認証情報をcredentialsに追加

大事な認証情報をcredentialsを使ってrailsに教えます。

```terminal
$ EDITOR=vi rails credentials:edit
```

```yaml
#以下を追記
aws:
  access_key_id: 先ほど控えたもの
  secret_access_key: 先ほど控えたもの
```
追記したら:wqで保存します。

## テーブルの作成
`$ rails active_storage:install`
`$ rails db:migrate`

activestorageで使用するテーブルを作成します。
アップロードするファイルとモデルの関連付けに使用されています。

## config/storage.ymlの編集


storage.ymlでストレージを定義します。

```erb:config/storage.yml  
test:
  service: Disk
  root: <%= Rails.root.join("tmp/storage") %>

local:
  service: Disk
  root: <%= Rails.root.join("storage") %>

amazon:
  service: S3
  access_key_id: <%= Rails.application.credentials.dig(:aws, :access_key_id) %>
  secret_access_key: <%= Rails.application.credentials.dig(:aws, :secret_access_key) %>
  region: ap-northeast-1
  bucket: バケットの名前

```

これは元々storage.yml内のコメントアウトされている内容をそのまま使っています。
access_key_idとsecret_access_keyはcredentialsで管理しましょう。


## config/environments/production.rbの編集

元々のファイルが

```ruby
  config.active_storage.service = :local
```
となっていると思いますので

```ruby
  config.active_storage.service = :amazon
```
と変更してproduction環境でamaozonという名前で定義したストレージを
使用するように変更しましょう。

## 必要なgemの追加

```ruby:Gemfile
gem 'mini_magick'
gem 'aws-sdk-s3', require: false
```

## Model、View、Controllerの修正


carrierwaveで書いていた部分を書き換えます。
モデル名、カラム名、view部分などは開発アプリごとに読み替えてください。

ActiveStorageでは他のカラムと同じようにActiveRecordで取り扱うことができます。

```ruby:app/models/user.rb
#以下を追記(１対多の関連付けの場合はhas_many_attachedとする）
  has_one_attached :image
```
```ruby:app/views/users/_form.html.slim　など
# 以下を追記、carrierwaveを使用している場合はそのままでOK
= f.file_field :image, accept: "image/png, image/jpeg, image/gif"
```


##まとめ

以上でActiveStorage + S3の導入終了です。
導入も中々簡単で良い感じです。
本番環境で上手く行かないですか？もしもherokuとdockerを使っているなら
**[こちら](https://qiita.com/daichi41/items/b1e7c530a2a182e3dddd)**の記事が参考になるかもしれません。