インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド4
AWS最終章です
静的コンテンツの処理
可用性の高いＳ３活用
課題 動画や高画質の画像やＺＩＰなどの容量の大きいファイルを１台のサーバーから配信するためには負担が大きいので複数のサーバーで負担を
分散するのだが、コストが気になる
解決 大容量のファイルをＳ３に配信し、そこから直接ファイルを配信することで、ネットワークの負担とＳ３の容量の問題を解決する
Ｓ３に保存したオブジェクトは公開設定にすることでユーザーに直接アクせすされる
配信ファイルを同期するためにＥＣ２間でファイルのコピーも不必要になる
実装
- 配信したいコンテンツをＳ３に配置➡ ユーザーが直接ダウンロードできるようになる
- Ｓ３にパケットを作成し、公開するコンテンツを入れる
- 公開設定でコンテンツごとのＵＲＬが発行される
- 発行されるＵＲＬをユーザに提供するか、リンクを張る
利点
Ｓ３を使えば、ネットワーク負担やデータ容量を気にする必要がない
Ｓ３は３か所以上のデータセンターでバックアップをしているので耐久性がたかい
各コンテンツにＵＲＬがあるので、ファイルをＳ３に置くだけでファイルの共有など広範囲なことにＯＫ
ちゅういてん
Ｓ３のコンテンツは独自のＤＮＳ名を付ける必要がある
Direct hosting
Ｓ３で直接ホスティング
課題 短期間の急激アクセス数増加に対して見積もっておく必要があるが、無駄にサーバーを増やすとコストがかかる
解決 Ｓ３をサーバーとして活用し、動画や静的ファイルをホスティングする ➡ Ｓ３には負担の限界がないので、対策がいらない
実装
- Ｓ３にバケットを入れコンテンツを公開するように設定
- Ｓ３のwebサイトホスティング機能をオンにして、インデックスページや、エラーページを設定することでＳ３単体でwebサイト単体でホストできる
利点
静的コンテンツへのアクセスをＳ３に任せることでwebシステムの可溶性と耐久性を簡単に高めることができる。
注意
Ｓ３ではサーバーサイドのプログラムを動かすことはできないので、ログインユーザーごとに異なるページを出せない
Ｓ３から配信したコンテンツにＪＳを埋め込み、非同期通信で別のサーバーからデータを取得したい場合、データ取得先のサーバーとＤＮＳが異なるため
ＪＳＯＮＰで通信
Private distribution
特定のユーザーへのデータ配布
課題 Ｓ３は可用性や耐久性に問題ないが、特定のユーザーにのみ配布するときに制限するのは難しい
解決 Ｓ３で提供される制限付きＵＲＬ発行機能を使うと、アクセス元のＩＰアドレスに対してアクセス可能期間を設定できる。
期限が切れたものや異なるＩＰアドレスを持つ人はダウンロードできない
実装
- Ｓ３のapitool や ＡＷＳ ＳＤＫを準備する
- 自らのシステムでユーザー認証を実施後、ユーザーに公開するコンテンツに対して、ＡＰＩで制限つきＵＲＬを生成
- 生成したＵＲＬ一覧で動的にwebページを生成 制限付きのＵＲＬをリンク先として利用する
利点
特定のユーザーだけが使えるので、プライベートコンテンツの配信に便利
実際のコンテンツダウンロードは、ＥＣ２を通さず、直接Ｓ３からなので、Ｓ３の特性を活用できる
cache distribution
ユーザーの物理的に近い位置へのデータ配置
課題 ユーザーエクスペリエンスの観点でいえば、距離が生じると、通信遅延が発生する
解決 コンテンツのキャッシュデータを利用する➡物理的に利用者に近いロケーションからコンテンツを配信できる
実装
ＡＷＳのCloudfront で世界中のキャッシュサーバーを利用
- オリジンサーバーを使用するようにcloudfrontを設定する➡ＤＮＳ名が発行される
- 独自のドメイン名を使ってよい➡ オリジンサーバーのＤＮＳ名のレコードに発行されるＤＮＳ名
利点
地理的に離れたユーザーにより良いユーザーエクスペリエンスを提供できる
ファイル負担分散効果がある （ファイルダウンロード処理を分散）
既存サーバー（オンプレやホスティングなどＥＣ２以外のサーバー）をオリジンサーバーにすることで、既存サーバーを生かしながら、パターンを適用可能
Ｓ３をオリジンサーバーにできる
注意
更新してもキャッシュサーバーは変更されないかも、
Rename distribution
課題 cache distribution を使用してコンテンツ配信する場合、オリジンサーバーを変更しても、エッジサーバー（cloudfront)のデータはタイムアウトになるまで更新されない
解決 ＵＲＬがカギになる 更新したいファイルを違うファイル名で配置して、アクセスＵＲＬ自体を変更することで常に新しいコンテンツを配信できる
実装
- コンテンツとは別にベースコンテンツ（ＵＲＬを含むＨＴＭＬファイル）を作成
- ベースコンテンツはキャッシュタイムを短くするか、常にオリジンサーバーから配信
- cloudfrontのときは、別名のＵＲＬでオリジンサーバーにも配備
- ベースコンテンツ内のＵＲＬを新しいコンテンツのＵＲＬへ変更する
利点
キャッシュタイムアウトを待たずに新しいコンテンツを配信できる
注意点
ベースコンテンツのキャッシュタイムアウトを短く設定する必要があるが、キャッシュ効果が薄くなる
古いファイルはキャッシュタイムアウトまでエッジサーバーに残るので必要ならば消す
Private cache distribution
CDN を用いたプライベート配信
課題 特定のユーザーに配信する場合、利用者を認証する必要がある
解決 署名付きＵＲＬ認証機能 （ アクセス元ＩＰアドレス、 ダウンロード可能期間 アクセス元地域） などで分別
➡より高い精度で特定のユーザーへの配信が可能になる
実装
- cloudfront apitool or AWS SDK
- EC2 のサーバーに秘密鍵登録して、署名付きＵＲＬの発行準備
- ユーザー認証をして、cloudfrontでＡＰＩを用いて署名付きＵＲＬ制作機能を利用
- ＵＲＬをリンク先として利用
利点
ＩＰアドレスと地域で特定されるユーザーのみ利用できる
実際のコンテンツダウンロードは直接cloudfrontから行うので負担と障害に強い
注意
認証システムや期限付きＵＲＬを発行するサーバーが必要になる
ユーザー認証が切れていなくても、ＵＲＬの有効期限が切れるとダウンロードできなくなる
インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド3
今日もAWSについて書きます
ＮＦＳ Replica
共有コンテンツの複製
課題 ＮＦＳを用いて複数サーバー間でファイルを共有している場合、サーバーのアクセス数が増えてくるとＮＦＳのパフォーマンス劣化がある
解決 共有ファイルを保管するＮＦＳのパフォーマンス劣化に対し、参照性能を改善する
各サーバーに仮想ディスクを個別に用意し、ＮＦＳサーバーの共有ファイルをコピーしておく ➡ 仮想ディスクがＮＦＳの参照専用レプリカになる
実装
- ＥＣ２インスタンスの仮想ディスクであるＥＢＳに、ＮＦＳサーバーのファイルをコピー
- ＥＣ２はＥＢＳのファイルを読み取ることでＮＦＳサーバーにアクセスするよりも高いパフォーマンス。
- ＥＣ２上にＮＦＳサーバーを構築し、共有ファイルを配置
- Auto scaling で起動するEC2(webserver) は起動時にまずＮＦＳサーバーをマウントし、ＥＢＳに内容をコピー
- 各EC2上のアプリケーションはＥＢＳを参照先にしておく
利点
ＮＦＳサーバー上の共有ファイルを更新すれば、それ以降に起動したＥＣ２ではそのファイルが使われることになる
各ＥＣ２のＥＢＳに共有ファイルが存在するので、ＮＦＳサーバーにアクセスする必要がないのでパフォーマンスが気にならない
ＮＦＳサーバーがＳＰＯＦにならない
注意点
共有ファイルを更新する際、ＮＦＳサーバー上のファイルを更新するだけでは各ＥＣ２に反映されない
rsync などを用いて同期させる必要がある
その他
ローカルディスクとしてＥＢＳを用いる代わりに、インスタンスストレージ（ＥＣ２のローカルディスク）を利用するとパフォーマンスが上がる
State sharing
ステート情報の共有
課題 動的なコンテンツを生成するとき、ユーザー固有の情報（ＨＴＴＰ）を利用することが多い
ＥＬＢの配下で複数のサーバーを動作させているときに、各サーバーでステート情報を持ちようにすると、サーバー障害時や数を減らすときに消滅してしまう
解決 スケールアウト構成でステート情報を保持するためのもの
ステート情報を耐久性の高いデータストア（メモリー・ディスク）において、複数のサーバーからその情報を参照する
するとサーバーがステートレスになる
実装
ＡＷＳのデータストアには Elastic chache , Simple DB(KVS), DynamoDB (KVS)
- それぞれの要件にステート情報を格納するためのデータストアを準備する
- データストアにはユーザーを特定するＩＤ（セッションＩＤやユーザーＩＤ）をキーにして、ユーザー情報を値として格納
- ＷＥＢ／ＡＰサーバーに情報を保管せず、データストアに保管して参照・更新を行う
利点
ステート情報を気にせずにスケールアウトできる
注意
複数のサーバーからステート情報が１か所に集まるため、データストアがネックにならないようにする 一番いいのはＤynamicDB
要件によってはＲＤＳやＳ３も利用できる
URL rewriting
静的コンテンツの退避
課題 webサービスをＥＣ２で提供するとき、スケールアウトかスケールアップをするが、大半は、静的コンテンツのリクエストであることが多く、それをどう
分散するかは重要
解決 静的コンテンツ分散はＳ３を使う ➡ ①静的コンテンツのＵＲＬをＳ３のＵＲＬに変える必要がある
②webサーバーのフィルター機能を利用して配信時にＵＲＬを変える
③Ｓ３から配信する代わりにコンテンツ配信サーバーからの配信
実装
- ＥＣ２上の静的コンテンツ（ＪＳ／ＣＳＳ・画像）の一部をＳ３にアップロード（同期）する
- 必要に応じて、静的コンテンツが同期されるＳ３をオリジナルとしたCloudfrontを作成
- ＨＴＭＬタグ上の静的コンテンツのＵＲＬをＳ３、もしくはCloudfront のものに書き換える
- Apacheのフィルターモジュールやプロキシとして用意したNginxなどで動的に書き換えることも可能
利点
静的コンテンツのアクセスをＳ３かcloudfrontに分散することにより、負担に強くなり、またＥＣ２のコスト削減にも
Cloudfrontは 全世界配信で距離のレイテンシーを解決できる
Nginxを利用している場合はフィルターに入れることで、元のＨＴＭＬファイルに手を付けづにパターンを適用できる
フィルターをオフにすることでcloudfrontを使わないこともできる
注意点
cloudfrontを使う場合はコンテンツがキャッシュされてしまうため、削除や更新に時間がかかる
rewrite proxy
ＵＲＬ書き換えプロキシの設置
課題 静的コンテンツをＳ３に配置するとき、ＵＲＬをＳ３に変更する必要があり、 コンテンツ内のフィルター設定など既存のシステムを設定し直す必要がある
解決 プロキシサーバをコンテンツを格納したサーバーの前に設定し、ＵＲＬをＳ３やCloudfrontに変更する
実装
- apache や Nginx などでプロキシサーバーを構築し、既存システムの前に設置
- ＥＬＢとＳ３の間にプロキシサーバーを設置
- プロキシサーバーにコンテンツ内のＵＲＬ書き換えルールを追加
- 必要に応じて、Auto scaling を適用する
利点
プロキシサーバーでＵＲＬを書き換えることで既存のシステムを修正せずに静的コンテンツの負担分散が可能になる
注意
ＳＰＯＦを作らないようにするため、プロキシサーバーも冗長化しておく必要がある
WEB/APサーバーはＥＬＢに間接的に配置されるのでAuto scaling によってサーバー（ＥＣ２）が増減しても、ＥＬＢに自動的にアタッチできない
Cache proxy
キャッシュの設置
課題 サーバーを複数利用するとコストがかかる
解決 パフォーマンスを上げる方法でコンテンツをキャッシュ化する方法がある
変化のない動的、静的コンテンツをサーバーの上流でキャッシュし、 キャッシュの期限が切れるまで配信パフォーマンスの高い上流のキャッシュサーバーでコンテンツ配信を行う方法である。
クラウドは仮想サーバーを簡単に導入できるのでキャッシュサーバーがないシステムに対しても可能
実装
- ＥＣ２上に、 Varnishなどのキャッシュサーバーソフトをインストールして、利用
- サーバーの前に配置
- キャッシュサーバーにオリジナルデータのサーバーやキャッシュ期限を設定
利点
サーバーに触れずにキャッシュを用いたコンテンツ配信が可能
特に動的コンテンツの場合、コンテンツの生成の負担を削減
ＨＴＴＰのヘッダーやＵＲＬ、ＣＯＯＫＩＥなどでキャッシュ化の対象にしたり、しなかったりの設定が柔軟
注意点
ＳＰＯＦを作らないためにはキャッシュサーバーも冗長化する必要がある
サーバーとして利用しているＥＣ２はＥＬＢに間接的に配置されるのでキャッシュサーバーのアタッチには工夫が必要
Scheduled Scale out パターン
スケジュールに合わせたサーバー増減
解決 瞬間的にアクセスが増えるタイミングがわかっているときには スケジュール されたスケールアウトが有効 ➡ 時間帯を指定して実行
実装
- スケールアウトパターンでAuto scaling を設定する
- ＥＣ２インスタンスを増加させたい時間帯を指定し、インスタンスの最小台数で変更する
- 指定した時刻になると、起動する
- 設定したトリガーに従い、負担が落ち着いたら、スケールインする
利点
自動的に増減する
ＥＬＢ配下に必要な数のＥＣ２インスタンスを並べることができるので、スケールアップと並べると処理能力の限界は極めて高い
注意
指定する時間はＵＴＣ時間
ＥＣ２だけでなく、ＥＬＢもスケールアウトする必要がある。この場合、 プレウォーミングを申請
インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド2
今日もAWSについて書きます
Deep health chech
システムのヘルスチェック
課題 ロードバランサーがＷＥＢサーバーの前にある場合、ＷＥＢサーバーが不調かどうかは把握できるが、それ以降の３つのサーバーの状態を把握できない。
それと同じプログラムで他の３つのサーバーの動作をチェックし、結果をロードバランサーに返す。
実装 ＡＷＳのロードバランサーＥＬＢのヘルスチェック機能は指定のＵＲＬへのＨＴＴＰアクセスの成否によりステータスを確認。 これを利用してヘルスチェック先を動的なページに設定する。
- ＥＬＢを起動してヘルスチェック機能を有効にする
- ＡＰサーバー上で動作するプログラムを作成。このプログラムはＤＢサーバーアクセスを伴う
- ＥＬＢのヘルスチェックＵＲＬは２のプログラムで、設定したリクエストに対してプログラムが動くようにする
- ＥＬＢからヘルスチェックを行う
システムの動作に必要なすべてのサーバーをチェックすることが可能
作り方によってはリクエストを受け付けないようにしたり、障害内容によってはカスタマイズされたエラー情報を出力したりすることが可能になる
注意点
サーバー数が多いとき、ヘルスチェック自体が負担になるのでチェックの時間間隔を考慮する
ＤＢサーバーがＳＰＯＦになっている場合、そこがダウンすると過剰反応して、すべてのサーバーを停止させてしまうかも
ＤＢサーバー部分がＳＰＯＦにならないように、ＤＢ replication パターンを併用することがいい
動的コンテンツの処理
Scale out
サーバー数の動的増減
課題 スケールアップ（高スペックのサーバーで処理能力を高めること）は処理単価が高くなる
サーバーのスペックには限界があ、無制限にあげられない。
解決
スケールアウト（同じようなスペックのサーバーを複数台並べる）
実装 ＥＬＢとCloudwatch と Auto scaling の３つのサービスを組み合わせることによって、負担に合わせて自動でスケールアウトできるシステム
利点
コスト削減
運用の手間が省ける
ＥＬＢの下に必要な数だけＥＣ２インスタンスを並べることができるので、スケールアップに比べると処理能力は極めて高い
注意点
特定の時間帯になると増えるように設定しておく
ＨＴＴＰセッション管理やＳＳＬ処理などＥＬＢに任せるか、サーバーで処理するのか考慮する
ＥＬＢにはスペックに応じて分散量を変える仕組みは備わっていないので、インスタンスタイプは統一したほうがいい
WEB/APサーバーのレイヤーに比べ、ＤＢサーバーレイヤーのスケールアウトは一般に難しい
Clone server
課題 スケールアウト構成ではスモールスタートの時に複数のサーバーを提供できる構成になっていないことが多い。必要な時に時間がかかる
解決 負担分散が考慮されていないシステムを簡単に負担分さん可能なシステムにする。 常にあるサーバーをマスターとして、追加するＡＭＩを用意する
コンテンツ同期やデータベース接続の調整を行っておく。ＡＭＩを起動しただけで、スケールアウトによる負担分散が可能になる
実装 ＥＬＢ と ＡＭＩを利用
コンテンツ同期の準備が整ったＡＭＩを作成し、負担が重くなれば、クローン用のＡＭＩからＥＣ２インスタンスを起動する。
- ＥＬＢを立ち上げて、ＥＣ２を配下に置く
- 現在稼働しているＥＣ２からクローンＥＣ２を作成し、ＥＬＢの配下に加える
- クローン用ＥＣ２は必要に応じて定期的にrsyncなどを用いてマスターＥＣ２のファイルを同期するようにしておく
- 負担に伴い、必要な数のクローン用のＥＣ２を稼働させ、ＥＬＢに追加する
利点
現状のシステムを変更することなく、容易にスケールアウトによる負担分散を行うことができる
注意点
マスターＥＣ２がＳＰＯＦになっていまう
マスターＥＣ２でデータベースが動作している場合、クローンＥＣ２をデータベースに接続せず、データベースはマスターＥＣ２に接続
ファイルのアップロードや書き込みは、処理をマスターＥＣ２で行う （apache のmod-proxy を用いて、該当のＵＲＬだけクローン用の仮想サーバーからマスターにつなげる）
ＮＦＳ sharing
共有コンテンツの利用
複数サーバーで負担分散した場合、コンテンツを同期させなければならない
マスターからスレーブに同期するときに遅れることがよく問題になる
もし、スレーブサーバーに書き込みが発生するとほかの者に反映されない
実装
- ＮＦＳサーバーをＥＣ２上に構築
- 共有したいコンテンツをＮＦＳサーバーに配置
- スケールアウトするサーバーたちからＮＦＳサーバーのコンテンツを参照するようにする
利点
共有コンテンツをＮＦＳに置くことでリアルタイムに共有できる
セットアップが楽
注意点
更新頻度の高いものはＮＦＳでの共有を用いるといい
ＮＦＳサーバーの管理が必要
ＥＣ２インスタンスが多くなるとＮＦＳアクセスのパフォーマンスの考慮がいる
ＮＦＳサーバーがＳＰＯＦになるのを防ぐためにGlusterFS などのソリューションを検討
インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド
今日はAWSについて書きたいと思います。
snapshot（ある瞬間のデータを複製したバックアップ） パターン
➡データのバックアップ
課題：データの保存としてテープのバックアップをすると自動化が困難である。また、テープの容量が有限なため完全な自動化ができない。
解決策：クラウドでは安全で容量制限がないストレージがある。安い プログラムを使用して自動化できる ＯＳごと複製できる
実装 ＥＢＳにスナップショット機能がついている ➡ Ｓ３に保存。 保存されたものはＥＢＳ上で新たに復元できる
ブートディスクとして使うとＡＭＩとして登録できる
利点・・・バックアップをプログラムから人手を返すことなく自動でできる
バックアップ先に耐久性の高いＳ３
ＥＢＳのデータを丸ごとバックアップできるので万が一の時にも簡単に復旧できる
ＯＳごとバックアップでき、ＡＭＩとして利用できるので、新たなＥＣ２インスタンスを起動することも可能
注意点・・・スナップショットを取得する際にデータの整合性を確保しなければならない。
サーバーの複製
課題 仮想サーバーでも依然として物理サーバーと同じくらい設定の手間がかかる
実装 ＯＳブートがあるＥＢＳからＡＭＩを作成すれば、ＡＭＩからＥＣ２をたくさん起動できる
利点
仮想環境済みのＡＭＩを使えば、それを基に立ち上げたＥＣ２インスタンスへの設定作業は不要になる
ＡＭＩは自分だけでなく、他人にもshareできる
注意点
どの時点でのスナップショットを所得するか、どのくらいのタイミングでＡＭＩを更新するかはケースバイケース
バージョンアップやパッチは個別に行う必要がある
Scale up
動的なサーバーのスペックアップ
解決したい課題 サーバーの必要なリソースを自動的に補いたい
解決 クラウドではスペックに応じて切り替えることができる
利点 システムの設計時に厳密にサーバースペックを見積もらなくていい
柔軟に対応でき、コスト面で無駄をなくせる
注意点
サーバースペックを変更するときには、ＥＣ２インスタンスを一時停止する必要がある。
処理待ちが大量に発生した時、一時的にサーバースペックを変更してその場をしのぎ、アプリやデータベースの改善をしてから元のスペックに戻す。
Ondemand Disk
動的なディスクの容量の増減
ディスク容量を事前に見積もるのは難しいので、ハードウェアの初期投資が無駄になってしまう可能性がある
解決 クラウドでは仮想ディスクを利用できる ➡いつでも好きなだけ容量を確保可能である。（オンでぃまんど）
ディスクは年々価格が下がっているので、いらなくなったら捨てるのが良い
実装 ＡＷＳのＥＢＳを使えばいつでも好きなタイミングで容量を確保できる
ディスクが必要になった時にＥＢＳスナップショットをとり、それを基に新しいＥＢＳを作成する➡ 新しいＥＢＳをＥＣ２にアタッチする➡ リサイズコマンドで新しい容量まで拡張する
ストライピングのときは複数のＥＢＳをアタッチし、ソフトウェアＲＡＩＤディスク構成にする
利点 コストの削減
ストライピングを行うことでディスクＩ／Ｏの性能を上げる
注意点 ＥＢＳはＳ３と違い、確保したディスク容量に対して課金する （どれほどつかわれているかに関わらず）
ＥＢＳはネットワーク経由でアクセスするため、より大きいサイズのＥＣ２インスタンスを利用するほうがＩ／Ｏ性能が高くなる
可用性向上
multi-server
サーバーの冗長化
課題 複数の物理サーバーを用意する方法がある
オンプレより簡単に環境を整えやすい
実装 ＥＬＢを利用する ＥＬＢはヘルスチェック機能があり、正常に稼働しているＥＣ２だけに振り分ける
利点
あるＥＣ２インスタンスに障害が起きても、システム全体としては稼働を続ける
ELB auto-scaleを組み合わせれば、障害があっても一定のＥＣ２を保てるので適切なＡＭＩを選択してＥＣ２を起動しておく必要がある
注意点
ＥＬＢと複数のＥＣ２を利用するのでコストがかかる
常に予備がある構成にする
ＩＰアドレスの動的な移動
解決したい課題
サーバーにパッチを当てたり、アップグレードをするためにサーバーの停止が必要となる。 サーバー停止＝サービスの停止 時間を短くしないといけない
解決 ➡ 従来では本来のサーバーの停止に備えて予備を用意するが、クラウドではこれがとても短くできる。
ＩＰアドレスを指定するＡＰＩもあるので サーバーの軌道からＩＰアドレスの設定までスクリプトを用いて自動化できる
実装 ＥＩＰ（elastic IP address) ＩＰアドレスを付け替えられる。 ＥＣ２インスタンスに対してＥＩＰを振り分ける
利点 ＥＩＰを付け替えるだけなので、ＤＮＳのＴＴＬに影響されずにサーバーを切り替えられる。
アップグレードの際、仮に切り替え先のサーバーでエラーが発生しても、即座に元のサーバーにＥＩＰを付け替えることでフォールバックできる。
ＥＩＰは別のＡＺにも適用できるのでリージョンごとに利用可能
注意点
ＥＩＰの切り替えには数十秒かかる
ＶＰＣの場合、固定のプライベートＩＰアドレスを割り当てることができる。
ネットワークカードを別のＥＣ２インスタンスにも適用可能
ただし、サブネットを超えてアドレスを付け替えることはできない
インフラエンジニアへの道 ICP、ルーティングの知識
- tcp/ip のデータを電気信号にして送る
プロトコルスタック（人間）はソケット（メモ帳）に記憶された制御情報を参照しながら動く
ソケットを作るときはメモリーを確保して、そこに初期情報の制御情報を載せてソケット完成
TCPヘッダーの送信元と宛先のポート番号で接続するソケットを特定する
closeの指示が出るまでconnectionは続く
シーケンス番号とACK番号でパケットが受信側に届いたことを確認する。
ACK番号とウィンドウ通知を相乗りさせて１つで送る（受信側の送信が多すぎるため）
受信➡データとTCPヘッダーの内容を調べて問題がない➡ACK番号➡データを受信バッファに保存➡データ断片を１つにまとめる
➡データをアプリケーションに渡す➡ウィンドウ通知
データを送る量➡MTU：１つのパケットで運ぶことができる最大のデジタルデータのこと。イーサネットでは１５００バイト
MSS：ヘッダーを除いて、１つのパケットで運べるTCPのデータの最大長
通信動作に用いる制御情報
①ヘッダーに書き込まれる情報
②ソケット（プロトコルスタックのメモリー）に書き込まれる内容
送信源IPアドレスは送信減となるLANアダプタを判断して、そのアドレスをセットする
- AWS 基礎からのネットワーク＆サーバー構築
サーバー構築のための知識
インターネットとのネットワーク ➡ ＴＣＰ／ＩＰ（インターネットプロトコル） ＩＰアドレス
ＤＮＳサーバー ➡ ドメイン名使用の際
ネットワーク構築の知識
- ＩＰアドレスに関する知識・・・・・ＩＰアドレスをどのように定めるのか。 ルータを介したインターネットとのデータの流れをどのように制御するか
ネットワーク構築
- ＩＰアドレスの範囲を決める・・・２のＮ上個で区切る
サブネットの考えかた
実際のネットワーク構築ではＣＩＤＲブロックをそのまま使わずに細分化して使う。 この細分化されたブロックのことをサブネットと呼ぶ
例 10.0.0.0/16 ➡ /24 で割って ２５６分割
➡ サブネットに分ける理由
- 物理的な隔離 ・・・・・社内ＬＡＮを構築するときに一回と二階で分けたいなど サブネットに分けておくと片方に影響が出た時にもう片方に出ずらい
- セキュリティ・・・・・・サブネットごとに別のネットワーク構築ができる
ルーティング情報・・・・ネットワークにデータを流すためにはせっていが必要（routing table route table ・・・宛先のＩＰアドレスがいくつの時にはどのネットワークに流れるべきか）
javaの基礎知識を得るために必要な本
javaを勉強する際に友だちがいいなと言って紹介してくれた本を書いておきます。
- Effective java
一目見たら難しそうに見えるかもしれないが、必死に食らいつくべし。
ただ Java の文法を勉強しながらプログラミングを学習しているだけでは学べない Java の仕組みや方法論を学べる．
- リーダブルコード
『リファクタリング』と通ずるところもあるが，読むべき．
Java しか触ったことがなかったとしても、「ヤバいコードはどの言語もだいたい同じ」と思ってもらえれば。
ジュンク堂が毎年やってる「このコンピュータ書籍がすごい！」というイベントによると、2015年まで3年連続売り上げ1位だったというお化け書籍。
- junit 実戦入門
JUnit を書けと言われても意味が理解できてなかったり，
カバレッジ100%を目指しながら自分のやっていることに疑問を感じている人は今すぐ読むべき．テストコードがあればすべてが解決されるわけではないけれども
「テストコードでどこまで解決できるだろう」とめっちゃ真剣になって極めようとおまえるはずです。
- プログラムはこうして作られる
初心者向けのプログラミング本によくある「if文はこうやって使います。for文はこうやって使います。以下略。」という教科書的な説明はない。テ◯リスのようなゲームを作り上げることを通してプログラミングの楽しさとかエッセンスを教えてくれる本。
Schemeを使用して、プログラミングパラダイムを解説、実装しています。
lambdaやDSL、高階関数、遅延評価など、新しい(?)ものがFORTRANの時代に存在していたという事実と、
言語が違うと思えるレベルのパラダイムシフトの実装可能性からLispの凄さが身に染みます。
ただし、この本はLISPのすごさではなく、各言語パラダイムに触れることが目的だと思います。
(この本がMITのプログラミング入門科目の教科書であったこと、現在は別言語が使用されている(python?)らしいことからもそうだとおもいます)
素晴らしいエンジニアになるために 人間としての基礎
- めもをとること
自分の頭の記憶には限界がある。その時点で覚えてても、席に戻ったら忘れてると思う
やる事をメモしておいて、報告する前にそのメモを見直すと、やり忘れで恥ずかしい思いをしなくて良くなる。
- 質問することは恥ずかしいことじゃない。本当に恥ずかしいのは質問せずに間違うこと
もちろん調べたり手を動かしたりしてやってみることは大事。でもどうしてもわからないなら先輩や上司を頼ろう。自分は「10分調べてわからなかったら質問することを検討する」というふうに決めている。
質問するときは「なにが知りたいのか」「そのために何をやったのか」を明確にしよう。
質問しなくとも、問題を解決しようとしたときに得られた情報ややったことは簡単にまとめておくと、あとで役に立つことがある。
- 相手がわかるように話そう
相手が知りたいことをきちんと聞き出そう。お互いに時間がもったいないからね。
うまく話せないときは、簡単に話すことを書き出しておこう。それを見ながら話せば間違えない。
- 自分の体をだいじにすること
栄養のバランス考えろと言いたいところなんだけど、ちょっとむずかしい気がするので、「とりあえずサラダを食べる」だけでもOK
野菜ジュースでもいいから、とにかく野菜も取りましょう。
- 自分の気持ちを健康に保つこと
ストレスやなれないことばかりで大変だけれども、自分自身を確立していかないといけないと感じた。
他人との比較も大事だが、じぶんをしっかりと持って、昨日の自分と戦うようなイメージを毎日おこなうこと
以上
