読者です 読者をやめる 読者になる 読者になる

インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド4

AWS最終章です
静的コンテンツの処理
 
可用性の高いS3活用
 
課題  動画や高画質の画像やZIPなどの容量の大きいファイルを1台のサーバーから配信するためには負担が大きいので複数のサーバーで負担を
    分散するのだが、コストが気になる
 
解決  大容量のファイルをS3に配信し、そこから直接ファイルを配信することで、ネットワークの負担とS3の容量の問題を解決する
     S3に保存したオブジェクトは公開設定にすることでユーザーに直接アクせすされる
     配信ファイルを同期するためにEC2間でファイルのコピーも不必要になる
 
実装 
 
  1. 配信したいコンテンツをS3に配置➡ ユーザーが直接ダウンロードできるようになる
  2. S3にパケットを作成し、公開するコンテンツを入れる
  3. 公開設定でコンテンツごとのURLが発行される
  4. 発行されるURLをユーザに提供するか、リンクを張る
 
利点
S3を使えば、ネットワーク負担やデータ容量を気にする必要がない
S3は3か所以上のデータセンターでバックアップをしているので耐久性がたかい
各コンテンツにURLがあるので、ファイルをS3に置くだけでファイルの共有など広範囲なことにOK
 
ちゅういてん
 
S3のコンテンツは独自のDNS名を付ける必要がある
 

Direct hosting
S3で直接ホスティング
 
課題   短期間の急激アクセス数増加に対して見積もっておく必要があるが、無駄にサーバーを増やすとコストがかかる
 
解決 S3をサーバーとして活用し、動画や静的ファイルをホスティングする  ➡ S3には負担の限界がないので、対策がいらない
 
実装 
  1. S3にバケットを入れコンテンツを公開するように設定
  2. S3のwebサイトホスティング機能をオンにして、インデックスページや、エラーページを設定することでS3単体でwebサイト単体でホストできる
利点
 
静的コンテンツへのアクセスをS3に任せることでwebシステムの可溶性と耐久性を簡単に高めることができる。
 
注意
 
S3ではサーバーサイドのプログラムを動かすことはできないので、ログインユーザーごとに異なるページを出せない
S3から配信したコンテンツにJSを埋め込み、非同期通信で別のサーバーからデータを取得したい場合、データ取得先のサーバーとDNSが異なるため
JSONPで通信
 

Private distribution
特定のユーザーへのデータ配布
 
課題  S3は可用性や耐久性に問題ないが、特定のユーザーにのみ配布するときに制限するのは難しい
 
解決 S3で提供される制限付きURL発行機能を使うと、アクセス元のIPアドレスに対してアクセス可能期間を設定できる。
    期限が切れたものや異なるIPアドレスを持つ人はダウンロードできない
 
実装
 
  1. S3のapitool や AWS SDKを準備する
  2. 自らのシステムでユーザー認証を実施後、ユーザーに公開するコンテンツに対して、APIで制限つきURLを生成
  3. 生成したURL一覧で動的にwebページを生成  制限付きのURLをリンク先として利用する
利点
 
特定のユーザーだけが使えるので、プライベートコンテンツの配信に便利
実際のコンテンツダウンロードは、EC2を通さず、直接S3からなので、S3の特性を活用できる
 

cache distribution 
ユーザーの物理的に近い位置へのデータ配置
 
課題 ユーザーエクスペリエンスの観点でいえば、距離が生じると、通信遅延が発生する
   
解決 コンテンツのキャッシュデータを利用する➡物理的に利用者に近いロケーションからコンテンツを配信できる
 
実装
 
AWSのCloudfront で世界中のキャッシュサーバーを利用
 
  1. オリジンサーバーを使用するようにcloudfrontを設定する➡DNS名が発行される
  2. 独自のドメイン名を使ってよい➡ オリジンサーバーのDNS名のレコードに発行されるDNS名
利点
 
地理的に離れたユーザーにより良いユーザーエクスペリエンスを提供できる
ファイル負担分散効果がある  (ファイルダウンロード処理を分散)
既存サーバー(オンプレやホスティングなどEC2以外のサーバー)をオリジンサーバーにすることで、既存サーバーを生かしながら、パターンを適用可能
S3をオリジンサーバーにできる
 
注意
 
キャッシュサーバーではオリジンサーバー(配信限)のキャッシュタイムアウト設定に基づいてキャッシングを行うのでキャッシュタイムアウト前に
更新してもキャッシュサーバーは変更されないかも、
 

Rename distribution
 
課題 cache  distribution を使用してコンテンツ配信する場合、オリジンサーバーを変更しても、エッジサーバー(cloudfront)のデータはタイムアウトになるまで更新されない
 
解決 URLがカギになる   更新したいファイルを違うファイル名で配置して、アクセスURL自体を変更することで常に新しいコンテンツを配信できる
 
実装   
 
  1. コンテンツとは別にベースコンテンツ(URLを含むHTMLファイル)を作成
  2. ベースコンテンツはキャッシュタイムを短くするか、常にオリジンサーバーから配信
  3. cloudfrontのときは、別名のURLでオリジンサーバーにも配備
  4. ベースコンテンツ内のURLを新しいコンテンツのURLへ変更する
利点
   キャッシュタイムアウトを待たずに新しいコンテンツを配信できる
 
注意点
 
ベースコンテンツのキャッシュタイムアウトを短く設定する必要があるが、キャッシュ効果が薄くなる
古いファイルはキャッシュタイムアウトまでエッジサーバーに残るので必要ならば消す
 

Private cache distribution
CDN を用いたプライベート配信
 
課題  特定のユーザーに配信する場合、利用者を認証する必要がある
 
解決 署名付きURL認証機能  ( アクセス元IPアドレス、 ダウンロード可能期間 アクセス元地域) などで分別
  ➡より高い精度で特定のユーザーへの配信が可能になる
 
実装
  1. cloudfront  apitool  or AWS SDK
  2. EC2 のサーバーに秘密鍵登録して、署名付きURLの発行準備
  3. ユーザー認証をして、cloudfrontでAPIを用いて署名付きURL制作機能を利用
  4. URLをリンク先として利用
利点
IPアドレスと地域で特定されるユーザーのみ利用できる
実際のコンテンツダウンロードは直接cloudfrontから行うので負担と障害に強い
 
注意
 
認証システムや期限付きURLを発行するサーバーが必要になる
ユーザー認証が切れていなくても、URLの有効期限が切れるとダウンロードできなくなる

インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド3

今日もAWSについて書きます
NFS Replica
共有コンテンツの複製
 
課題  NFSを用いて複数サーバー間でファイルを共有している場合、サーバーのアクセス数が増えてくるとNFSのパフォーマンス劣化がある
 
解決  共有ファイルを保管するNFSのパフォーマンス劣化に対し、参照性能を改善する
    各サーバーに仮想ディスクを個別に用意し、NFSサーバーの共有ファイルをコピーしておく ➡ 仮想ディスクがNFSの参照専用レプリカになる
 
実装 
  1. EC2インスタンスの仮想ディスクであるEBSに、NFSサーバーのファイルをコピー
  2.    EC2はEBSのファイルを読み取ることでNFSサーバーにアクセスするよりも高いパフォーマンス。
  3.    EC2上にNFSサーバーを構築し、共有ファイルを配置
  4.    Auto scaling で起動するEC2(webserver) は起動時にまずNFSサーバーをマウントし、EBSに内容をコピー
  5.    各EC2上のアプリケーションはEBSを参照先にしておく
利点
 
NFSサーバー上の共有ファイルを更新すれば、それ以降に起動したEC2ではそのファイルが使われることになる
各EC2のEBSに共有ファイルが存在するので、NFSサーバーにアクセスする必要がないのでパフォーマンスが気にならない
NFSサーバーがSPOFにならない
 
注意点
 
共有ファイルを更新する際、NFSサーバー上のファイルを更新するだけでは各EC2に反映されない
rsync などを用いて同期させる必要がある
 
その他
 
ローカルディスクとしてEBSを用いる代わりに、インスタンスストレージ(EC2のローカルディスク)を利用するとパフォーマンスが上がる
 
 
 

State sharing 
ステート情報の共有
 
課題  動的なコンテンツを生成するとき、ユーザー固有の情報(HTTP)を利用することが多い
    ELBの配下で複数のサーバーを動作させているときに、各サーバーでステート情報を持ちようにすると、サーバー障害時や数を減らすときに消滅してしまう
 
解決  スケールアウト構成でステート情報を保持するためのもの
    ステート情報を耐久性の高いデータストア(メモリー・ディスク)において、複数のサーバーからその情報を参照する
    するとサーバーがステートレスになる
 
実装
    AWSのデータストアには Elastic chache , Simple DB(KVS), DynamoDB (KVS)
  1.     それぞれの要件にステート情報を格納するためのデータストアを準備する
  2. データストアにはユーザーを特定するID(セッションIDやユーザーID)をキーにして、ユーザー情報を値として格納
  3. WEB/APサーバーに情報を保管せず、データストアに保管して参照・更新を行う
利点
ステート情報を気にせずにスケールアウトできる
 
注意
 
複数のサーバーからステート情報が1か所に集まるため、データストアがネックにならないようにする 一番いいのはDynamicDB
要件によってはRDSやS3も利用できる
                                                          
URL rewriting 
静的コンテンツの退避
 
課題  webサービスをEC2で提供するとき、スケールアウトかスケールアップをするが、大半は、静的コンテンツのリクエストであることが多く、それをどう
    分散するかは重要
 
解決  静的コンテンツ分散はS3を使う ➡ ①静的コンテンツのURLをS3のURLに変える必要がある
                      ②webサーバーのフィルター機能を利用して配信時にURLを変える
                      ③S3から配信する代わりにコンテンツ配信サーバーからの配信
実装 
  1. EC2上の静的コンテンツ(JS/CSS・画像)の一部をS3にアップロード(同期)する
  2. 必要に応じて、静的コンテンツが同期されるS3をオリジナルとしたCloudfrontを作成
  3. HTMLタグ上の静的コンテンツのURLをS3、もしくはCloudfront のものに書き換える
  4. Apacheのフィルターモジュールやプロキシとして用意したNginxなどで動的に書き換えることも可能
利点
静的コンテンツのアクセスをS3かcloudfrontに分散することにより、負担に強くなり、またEC2のコスト削減にも
Cloudfrontは 全世界配信で距離のレイテンシーを解決できる
Nginxを利用している場合はフィルターに入れることで、元のHTMLファイルに手を付けづにパターンを適用できる
フィルターをオフにすることでcloudfrontを使わないこともできる
 
注意点
cloudfrontを使う場合はコンテンツがキャッシュされてしまうため、削除や更新に時間がかかる
 

rewrite proxy 
URL書き換えプロキシの設置
 
課題  静的コンテンツをS3に配置するとき、URLをS3に変更する必要があり、 コンテンツ内のフィルター設定など既存のシステムを設定し直す必要がある
 
解決   プロキシサーバをコンテンツを格納したサーバーの前に設定し、URLをS3やCloudfrontに変更する
 
実装  
  1. apache や Nginx などでプロキシサーバーを構築し、既存システムの前に設置
  2. ELBとS3の間にプロキシサーバーを設置
  3. プロキシサーバーにコンテンツ内のURL書き換えルールを追加
  4. 必要に応じて、Auto scaling を適用する
利点
プロキシサーバーでURLを書き換えることで既存のシステムを修正せずに静的コンテンツの負担分散が可能になる
 
注意
 
SPOFを作らないようにするため、プロキシサーバーも冗長化しておく必要がある
WEB/APサーバーはELBに間接的に配置されるのでAuto scaling によってサーバー(EC2)が増減しても、ELBに自動的にアタッチできない
 

Cache proxy 
キャッシュの設置
 
課題  サーバーを複数利用するとコストがかかる
 
解決  パフォーマンスを上げる方法でコンテンツをキャッシュ化する方法がある
    変化のない動的、静的コンテンツをサーバーの上流でキャッシュし、 キャッシュの期限が切れるまで配信パフォーマンスの高い上流のキャッシュサーバーでコンテンツ配信を行う方法である。
  クラウドは仮想サーバーを簡単に導入できるのでキャッシュサーバーがないシステムに対しても可能
 
実装 
  1. EC2上に、 Varnishなどのキャッシュサーバーソフトをインストールして、利用
  2. サーバーの前に配置
  3. キャッシュサーバーにオリジナルデータのサーバーやキャッシュ期限を設定
利点
 
サーバーに触れずにキャッシュを用いたコンテンツ配信が可能
特に動的コンテンツの場合、コンテンツの生成の負担を削減
HTTPのヘッダーやURL、COOKIEなどでキャッシュ化の対象にしたり、しなかったりの設定が柔軟
 
注意点
 
SPOFを作らないためにはキャッシュサーバーも冗長化する必要がある
サーバーとして利用しているEC2はELBに間接的に配置されるのでキャッシュサーバーのアタッチには工夫が必要
 

Scheduled Scale out パターン
 
スケジュールに合わせたサーバー増減
 
課題   クラウド環境で構築された中で、高いトラフィックを処理する場合、スケールアウトが効果的
    急激(5分以内にトラフィックが倍増するようなケース)アクセス増の時にインスタンスの起動が追いつかない
 
解決  瞬間的にアクセスが増えるタイミングがわかっているときには スケジュール されたスケールアウトが有効  ➡ 時間帯を指定して実行
 
実装  
 
  1. スケールアウトパターンでAuto scaling を設定する
  2. EC2インスタンスを増加させたい時間帯を指定し、インスタンスの最小台数で変更する
  3. 指定した時刻になると、起動する
  4. 設定したトリガーに従い、負担が落ち着いたら、スケールインする
利点
自動的に増減する
ELB配下に必要な数のEC2インスタンスを並べることができるので、スケールアップと並べると処理能力の限界は極めて高い
 
注意
 
指定する時間はUTC時間
EC2だけでなく、ELBもスケールアウトする必要がある。この場合、 プレウォーミングを申請

 

インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド2

今日もAWSについて書きます
Deep health chech 
システムのヘルスチェック
 
課題 ロードバランサーがWEBサーバーの前にある場合、WEBサーバーが不調かどうかは把握できるが、それ以降の3つのサーバーの状態を把握できない。
 
解決策 クラウドロードバランサーが持つヘルスチェック機能を使い、PHPやJAVAservlet などの動的なページをチェックするように設定する。
    それと同じプログラムで他の3つのサーバーの動作をチェックし、結果をロードバランサーに返す。
 
実装  AWSのロードバランサーELBのヘルスチェック機能は指定のURLへのHTTPアクセスの成否によりステータスを確認。 これを利用してヘルスチェック先を動的なページに設定する。
 
  1.  ELBを起動してヘルスチェック機能を有効にする
  2. APサーバー上で動作するプログラムを作成。このプログラムはDBサーバーアクセスを伴う
  3. ELBのヘルスチェックURLは2のプログラムで、設定したリクエストに対してプログラムが動くようにする
  4. ELBからヘルスチェックを行う
利点 
システムの動作に必要なすべてのサーバーをチェックすることが可能
作り方によってはリクエストを受け付けないようにしたり、障害内容によってはカスタマイズされたエラー情報を出力したりすることが可能になる
 
注意点
 
サーバー数が多いとき、ヘルスチェック自体が負担になるのでチェックの時間間隔を考慮する
DBサーバーがSPOFになっている場合、そこがダウンすると過剰反応して、すべてのサーバーを停止させてしまうかも
DBサーバー部分がSPOFにならないように、DB replication パターンを併用することがいい
 

動的コンテンツの処理
 
Scale out 
サーバー数の動的増減
 
課題 スケールアップ(高スペックのサーバーで処理能力を高めること)は処理単価が高くなる
    サーバーのスペックには限界があ、無制限にあげられない。
 
解決
スケールアウト(同じようなスペックのサーバーを複数台並べる)
クラウドでは変動が激しいトラフィックの変化に柔軟に対応できる。
 
実装  ELBとCloudwatch と Auto scaling の3つのサービスを組み合わせることによって、負担に合わせて自動でスケールアウトできるシステム
 
  1. ELBに(WEB/APサーバーとして)EC2を複数並べる
  2. EC2を新たに起動するときに利用するAMIを作成
  3. EC2を増減させる条件の定義をする ➡ EC2の平均CPU使用率、ネットワーク流量、セッション数、EBSのレイテンシーなどがよく使われる
  4. 条件をcloudwatchを使って監視し、一定の条件を満たすとアラームが鳴るように設定
  5. アラームを受けた際、Auto scaling がEC2数を増減するように設定する
  6. 例えば CPU使用率が70%以上の状態が5分以上続いたらあらかじめ用意していたAMIを使ってEC2インスタンスを2つ起動する。など
利点
トラフィック数の増大に合わせて自動的にEC2インスタンスを増やすことができるので、サービスの継続につながる
コスト削減
運用の手間が省ける
ELBの下に必要な数だけEC2インスタンスを並べることができるので、スケールアップに比べると処理能力は極めて高い
 
注意点
 
数分間でトラフィックが数倍になるような急激なトラフィックの変動には対処できない➡ 判断してから実際に増やすためには時間がかかるため
特定の時間帯になると増えるように設定しておく  
あらかじめ余分なEC2インスタンスを用意して負担に耐えられるようにしておき、その後、不要な分のEC2インスタンスを減らす
HTTPセッション管理やSSL処理などELBに任せるか、サーバーで処理するのか考慮する
ELBにはスペックに応じて分散量を変える仕組みは備わっていないので、インスタンスタイプは統一したほうがいい
WEB/APサーバーのレイヤーに比べ、DBサーバーレイヤーのスケールアウトは一般に難しい
耐障害性を高めるためにも複数のAZに分散してスケールアウトさせたほうが良い。 増加させるインスタンス数はAZ数の倍数にしておくとよい。
 

Clone server

 
課題  スケールアウト構成ではスモールスタートの時に複数のサーバーを提供できる構成になっていないことが多い。必要な時に時間がかかる
 
解決  負担分散が考慮されていないシステムを簡単に負担分さん可能なシステムにする。 常にあるサーバーをマスターとして、追加するAMIを用意する
    コンテンツ同期やデータベース接続の調整を行っておく。AMIを起動しただけで、スケールアウトによる負担分散が可能になる
 
実装  ELB と AMIを利用  
     コンテンツ同期の準備が整ったAMIを作成し、負担が重くなれば、クローン用のAMIからEC2インスタンスを起動する。
 
  1. ELBを立ち上げて、EC2を配下に置く
  2. 現在稼働しているEC2からクローンEC2を作成し、ELBの配下に加える
  3. クローン用EC2は必要に応じて定期的にrsyncなどを用いてマスターEC2のファイルを同期するようにしておく
  4. 負担に伴い、必要な数のクローン用のEC2を稼働させ、ELBに追加する
利点
現状のシステムを変更することなく、容易にスケールアウトによる負担分散を行うことができる
 
 
注意点
マスターEC2がSPOFになっていまう
マスターEC2でデータベースが動作している場合、クローンEC2をデータベースに接続せず、データベースはマスターEC2に接続
ファイルのアップロードや書き込みは、処理をマスターEC2で行う (apache のmod-proxy を用いて、該当のURLだけクローン用の仮想サーバーからマスターにつなげる)
 

NFS sharing 
共有コンテンツの利用
 
複数サーバーで負担分散した場合、コンテンツを同期させなければならない
マスターからスレーブに同期するときに遅れることがよく問題になる
もし、スレーブサーバーに書き込みが発生するとほかの者に反映されない
 
実装
  1. NFSサーバーをEC2上に構築
  2. 共有したいコンテンツをNFSサーバーに配置
  3. スケールアウトするサーバーたちからNFSサーバーのコンテンツを参照するようにする
利点
共有コンテンツをNFSに置くことでリアルタイムに共有できる
セットアップが楽
 
注意点
更新頻度の高いものはNFSでの共有を用いるといい
NFSサーバーの管理が必要
EC2インスタンスが多くなるとNFSアクセスのパフォーマンスの考慮がいる
NFSサーバーがSPOFになるのを防ぐためにGlusterFS などのソリューションを検討

インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド

今日はAWSについて書きたいと思います。

snapshot(ある瞬間のデータを複製したバックアップ) パターン

➡データのバックアップ
課題:データの保存としてテープのバックアップをすると自動化が困難である。また、テープの容量が有限なため完全な自動化ができない。
 
解決策:クラウドでは安全で容量制限がないストレージがある。安い  プログラムを使用して自動化できる  OSごと複製できる
 
実装  EBSにスナップショット機能がついている ➡ S3に保存。 保存されたものはEBS上で新たに復元できる
     ブートディスクとして使うとAMIとして登録できる
 
利点・・・バックアップをプログラムから人手を返すことなく自動でできる
     バックアップ先に耐久性の高いS3
     EBSのデータを丸ごとバックアップできるので万が一の時にも簡単に復旧できる
     OSごとバックアップでき、AMIとして利用できるので、新たなEC2インスタンスを起動することも可能
 
注意点・・・スナップショットを取得する際にデータの整合性を確保しなければならない。

サーバーの複製
 
課題 仮想サーバーでも依然として物理サーバーと同じくらい設定の手間がかかる
      
解決  クラウド上でOSやミドルウェア、アプリケーションを設定でき、いつでも再利用できる
 
実装  OSブートがあるEBSからAMIを作成すれば、AMIからEC2をたくさん起動できる
 
利点
    仮想環境済みのAMIを使えば、それを基に立ち上げたEC2インスタンスへの設定作業は不要になる
    AMIは自分だけでなく、他人にもshareできる
 
注意点
    どの時点でのスナップショットを所得するか、どのくらいのタイミングでAMIを更新するかはケースバイケース
    バージョンアップやパッチは個別に行う必要がある

Scale up

 
動的なサーバーのスペックアップ
 
解決したい課題   サーバーの必要なリソースを自動的に補いたい
 
解決  クラウドではスペックに応じて切り替えることができる
 
実装  EC2インスタンスを起動してvmstatやcloudwatchでリソースを確認して、不足の場合はコンソールからインスタンスタイプを変更できる
 
利点   システムの設計時に厳密にサーバースペックを見積もらなくていい
     柔軟に対応でき、コスト面で無駄をなくせる
 
注意点
 
サーバースペックを変更するときには、EC2インスタンスを一時停止する必要がある。
インスタンスタイプの上限を超えることはできないので最も性能が高いインスタンスを選んで、scale out を採用するなど柔軟な対策が必要
 
処理待ちが大量に発生した時、一時的にサーバースペックを変更してその場をしのぎ、アプリやデータベースの改善をしてから元のスペックに戻す。
 

Ondemand Disk 

 
動的なディスクの容量の増減
 
ディスク容量を事前に見積もるのは難しいので、ハードウェアの初期投資が無駄になってしまう可能性がある
 
解決 クラウドでは仮想ディスクを利用できる  ➡いつでも好きなだけ容量を確保可能である。(オンでぃまんど)
                        ディスクは年々価格が下がっているので、いらなくなったら捨てるのが良い
 
実装  AWSのEBSを使えばいつでも好きなタイミングで容量を確保できる   
    ディスクが必要になった時にEBSスナップショットをとり、それを基に新しいEBSを作成する➡ 新しいEBSをEC2にアタッチする➡ リサイズコマンドで新しい容量まで拡張する
 
ストライピングのときは複数のEBSをアタッチし、ソフトウェアRAIDディスク構成にする
 
利点 コストの削減
   ストライピングを行うことでディスクI/Oの性能を上げる
 
注意点 EBSはS3と違い、確保したディスク容量に対して課金する (どれほどつかわれているかに関わらず)
 
EBSはネットワーク経由でアクセスするため、より大きいサイズのEC2インスタンスを利用するほうがI/O性能が高くなる

可用性向上
 
multi-server 
 
サーバーの冗長化
 
課題  複数の物理サーバーを用意する方法がある
    サーバー機器やロードバランサーなど、冗長化に必要な時は費用が掛かる
 
解決・・・・仮想サーバーを複数台並べ、クラウドにあるロードバランサを利用する(multi-server)
              オンプレより簡単に環境を整えやすい
 
実装  ELBを利用する  ELBはヘルスチェック機能があり、正常に稼働しているEC2だけに振り分ける
 
 ELBを複数のEC2インスタンスにひもつける➡ インスタンスのステータス確認を行う
 
利点
 
あるEC2インスタンスに障害が起きても、システム全体としては稼働を続ける
ELB auto-scaleを組み合わせれば、障害があっても一定のEC2を保てるので適切なAMIを選択してEC2を起動しておく必要がある
 
注意点
 
ELBと複数のEC2を利用するのでコストがかかる
常に予備がある構成にする   
 

IPアドレスの動的な移動
     
解決したい課題
 
サーバーにパッチを当てたり、アップグレードをするためにサーバーの停止が必要となる。 サーバー停止=サービスの停止   時間を短くしないといけない
 
解決 ➡ 従来では本来のサーバーの停止に備えて予備を用意するが、クラウドではこれがとても短くできる。
 
IPアドレスを指定するAPIもあるので サーバーの軌道からIPアドレスの設定までスクリプトを用いて自動化できる
 
実装  EIP(elastic IP address)  IPアドレスを付け替えられる。 EC2インスタンスに対してEIPを振り分ける
 
利点 EIPを付け替えるだけなので、DNSのTTLに影響されずにサーバーを切り替えられる。
    アップグレードの際、仮に切り替え先のサーバーでエラーが発生しても、即座に元のサーバーにEIPを付け替えることでフォールバックできる。
    EIPは別のAZにも適用できるのでリージョンごとに利用可能
 
注意点 
 EIPの切り替えには数十秒かかる
 VPCの場合、固定のプライベートIPアドレスを割り当てることができる。
 ネットワークカードを別のEC2インスタンスにも適用可能
 ただし、サブネットを超えてアドレスを付け替えることはできない

インフラエンジニアへの道 ICP、ルーティングの知識

  • tcp/ip のデータを電気信号にして送る

プロトコルスタック(人間)はソケット(メモ帳)に記憶された制御情報を参照しながら動く

ソケットを作るときはメモリーを確保して、そこに初期情報の制御情報を載せてソケット完成
 
接続方法・・・・TCP担当部分で接続を表す制御情報を記載したTCPヘッダーを作ること
TCPヘッダーの送信元と宛先のポート番号で接続するソケットを特定する
TCP➡IP(パケットを運ぶ)➡サーバー(IP)➡サーバーTCP➡ソケット 
 closeの指示が出るまでconnectionは続く
シーケンス番号とACK番号でパケットが受信側に届いたことを確認する。
ACK番号とウィンドウ通知を相乗りさせて1つで送る(受信側の送信が多すぎるため)
 
受信➡データとTCPヘッダーの内容を調べて問題がない➡ACK番号➡データを受信バッファに保存➡データ断片を1つにまとめる
➡データをアプリケーションに渡す➡ウィンドウ通知
 
データを送る量➡MTU:1つのパケットで運ぶことができる最大のデジタルデータのこと。イーサネットでは1500バイト
MSS:ヘッダーを除いて、1つのパケットで運べるTCPのデータの最大長
 
通信動作に用いる制御情報
①ヘッダーに書き込まれる情報
②ソケット(プロトコルスタックのメモリー)に書き込まれる内容     
 
IPヘッダーの宛先IPアドレスには通信相手のIPアドレスをセットする
送信源IPアドレスは送信減となるLANアダプタを判断して、そのアドレスをセットする
 
IPアドレスはルーティングテーブルのgatewayの値でパケットを渡す相手を判断する
  • AWS 基礎からのネットワーク&サーバー構築

サーバー構築のための知識

 
  1. サーバーOSのインストール
  2. 各ソフトウェアのインストールや設定方法(サーバー ➡Apache 、nginx   データベース  ➡my sql メールサーバー ➡ sendmail
ネットワーク構築
 
インターネットとのネットワーク ➡ TCP/IP(インターネットプロトコル) IPアドレス
 
DNSサーバー ➡ ドメイン名使用の際
 
ネットワーク構築の知識
 
  1. IPアドレスに関する知識・・・・・IPアドレスをどのように定めるのか。 ルータを介したインターネットとのデータの流れをどのように制御するか
  • ネットワークで使うIPアドレス範囲を定める
  • IPアドレスを割り当て、データがルーターから出ていくように構成する
  • DNSサーバーにドメイン名とIPアドレスの対応を割り当てる
  1. DNSサーバーに関する知識・・・・・ドメイン名とIPアドレスを結び付けるには、どうすればいいのっか。 どのようにドメイン名とIPアドレスは相互に変換されているのか??
NATサーバー(network address transmission)・・・・内部だけで通用するアドレスを外部とも通信できるアドレスに変換する ➡片方向からの接続を許す 
 
 
ネットワーク構築
 
  1. IPアドレスの範囲を決める・・・2のN上個で区切る
 
 
 
サブネットの考えかた
 
実際のネットワーク構築ではCIDRブロックをそのまま使わずに細分化して使う。  この細分化されたブロックのことをサブネットと呼ぶ
 
例 10.0.0.0/16 ➡ /24 で割って 256分割
 
 
➡ サブネットに分ける理由
  1. 物理的な隔離  ・・・・・社内LANを構築するときに一回と二階で分けたいなど   サブネットに分けておくと片方に影響が出た時にもう片方に出ずらい
  2. セキュリティ・・・・・・サブネットごとに別のネットワーク構築ができる
ルーティング情報・・・・ネットワークにデータを流すためにはせっていが必要(routing table  route table ・・・宛先のIPアドレスがいくつの時にはどのネットワークに流れるべきか)

 

 

javaの基礎知識を得るために必要な本

javaを勉強する際に友だちがいいなと言って紹介してくれた本を書いておきます。

 

一目見たら難しそうに見えるかもしれないが、必死に食らいつくべし。
ただ Java の文法を勉強しながらプログラミングを学習しているだけでは学べない Java の仕組みや方法論を学べる.

  • リーダブルコード

リファクタリング』と通ずるところもあるが,読むべき.
Java しか触ったことがなかったとしても、「ヤバいコードはどの言語もだいたい同じ」と思ってもらえれば。
ジュンク堂が毎年やってる「このコンピュータ書籍がすごい!」というイベントによると、2015年まで3年連続売り上げ1位だったというお化け書籍。

JUnit を書けと言われても意味が理解できてなかったり,
カバレッジ100%を目指しながら自分のやっていることに疑問を感じている人は今すぐ読むべき.テストコードがあればすべてが解決されるわけではないけれども

「テストコードでどこまで解決できるだろう」とめっちゃ真剣になって極めようとおまえるはずです。

  • プログラムはこうして作られる

初心者向けのプログラミング本によくある「if文はこうやって使います。for文はこうやって使います。以下略。」という教科書的な説明はない。テ◯リスのようなゲームを作り上げることを通してプログラミングの楽しさとかエッセンスを教えてくれる本。

Schemeを使用して、プログラミングパラダイムを解説、実装しています。
lambdaやDSL高階関数、遅延評価など、新しい(?)ものがFORTRANの時代に存在していたという事実と、
言語が違うと思えるレベルのパラダイムシフトの実装可能性からLispの凄さが身に染みます。
ただし、この本はLISPのすごさではなく、各言語パラダイムに触れることが目的だと思います。
(この本がMITのプログラミング入門科目の教科書であったこと、現在は別言語が使用されている(python?)らしいことからもそうだとおもいます)

 

 

 

 

 

 

素晴らしいエンジニアになるために 人間としての基礎 

  • めもをとること

自分の頭の記憶には限界がある。その時点で覚えてても、席に戻ったら忘れてると思う

やる事をメモしておいて、報告する前にそのメモを見直すと、やり忘れで恥ずかしい思いをしなくて良くなる。

  • 質問することは恥ずかしいことじゃない。本当に恥ずかしいのは質問せずに間違うこと

もちろん調べたり手を動かしたりしてやってみることは大事。でもどうしてもわからないなら先輩や上司を頼ろう。自分は「10分調べてわからなかったら質問することを検討する」というふうに決めている。

質問するときは「なにが知りたいのか」「そのために何をやったのか」を明確にしよう。

質問しなくとも、問題を解決しようとしたときに得られた情報ややったことは簡単にまとめておくと、あとで役に立つことがある。

  • 相手がわかるように話そう

相手が知りたいことをきちんと聞き出そう。お互いに時間がもったいないからね。

うまく話せないときは、簡単に話すことを書き出しておこう。それを見ながら話せば間違えない。

  • 自分の体をだいじにすること

栄養のバランス考えろと言いたいところなんだけど、ちょっとむずかしい気がするので、「とりあえずサラダを食べる」だけでもOK

野菜ジュースでもいいから、とにかく野菜も取りましょう。

  • 自分の気持ちを健康に保つこと

ストレスやなれないことばかりで大変だけれども、自分自身を確立していかないといけないと感じた。

他人との比較も大事だが、じぶんをしっかりと持って、昨日の自分と戦うようなイメージを毎日おこなうこと

 

以上