月別: 2018年8月

AWS 認定試験準備ワークショップを受けました

gTUjFXqCGAwr コメントをする

AWS 認定試験準備ワークショップ

https://pages.awscloud.com/event_JAPAN_certified-sa-associate.html

を受けたので、そのときのレポート

 

このセミナーでは、問題の解き方が主になります。
個々のサービスの詳細な説明はしません。

まず初めに、この資格は、AWSを使って設計ができることの証明です。

メリットとしては、客観的な評価が得られること
AWS認定の期限は2年
更新するためには、繰り返し受験する必要がある。

ソリューションアーキテクトに関する具体的な内容
　→ 要件に対して、AWSアーキテクチャのベストプラクティスを用いてソリューションを定義できること

現在、試験は旧バージョンと新バージョンがある。
合格した結果得られる資格は一緒。
新バージョンと旧バージョンの違いは、出題されるサービスの内容が新しいか古いかの違い

出題内容は4つの分野に分けられる。

  • 分野1：可溶性、コスト効率、スケーラブルなシステムの設計
    出題率：60%
  • 分野2：実装・デプロイ
    出題率：10%
  • 分野3：データセキュリティ
    出題率：20%
  • 分野4：トラブルシューティング
    出題率：10%

分野1がもっとも多く出題される。

問題となっているユースケースをサービスを使って解決するための問題が出る

設問は選択式の問題

今日の講義では、問題の狙いを見極めるポイントや答えのポイントを説明する。

分野1:可溶性、コスト効率、スケーラブルなシステムの設計

可用性、コスト効率、耐障害性に優れたスケーラブルなシステムの設計

最も出題数が多い分野

試験において重要なのが、これらの4つ（可用性、コスト効率、耐障害性、スケーラブル）を満たすために

どのようなサービスを組み合わせるのか知っていること。

※可用性とは
→ システムが停止してしまったときに、復旧までの時間が短いこと
例えば、ec2が1台で動いているのであれば、停止したときのために Load Balancing を使う、など。

※耐障害性とは
→ 障害が起きてもサービスが動き続けられるかということ。

※スケーラブルとは
→ システムの性能が足りなくなったときに、Auto Scaling する仕組みのこと
例えば SQS など

原則の1つ目

「疎結合で柔軟に」

システムが疎であるほど、スケーラビリティがあがる。

ポイントとしては、個々の固有の情報に依存しないこと

例えば、 IP アドレスを固定にせずに、 DNS とエンドポイント名を使うなど。

リソース固有の情報に依存しないサービス

  • ELB
  • RDS
  • Route 53
  • EIP（再マッピングが可能）

他のコンポーネントの健全性を前提にしない

  • ELB
  • SQS
  • SNS

 

練習問題

疎結合アーキテクチャの実装を用意にするものはどれですか？

選択肢

1:Cloud Formation

2:SQS

3:Croud Trail

4:ELB

5:Elastic Mapreduce

 

解答

2, 4

 

解説

1: 違う。コンポーネントのスタックを起動するサービス。

3: 違う。これは。ロギングサービス
　awsのapiを全てロギングするサービス
なので障害が起こったときに、原因追求になる。

5: 違う。これはマネージド　hadoop　のサービス

 

実際に問題を解く際には、消去方が良い。

 

原則2つ目

「障害に備えた設計にすれば問題は起きない。」

各コンポーネントに障害が生じたらどうなるか？という観点が大事。

高可用性と耐障害性の考え方の違い

 

例えば、前提として、

SLAを満たすには4つのEC2インスタンスが必要という状況だった場合に、

AZ で障害が起きた場合を考える。

 

耐障害性のない例だと

AZ2つに、ec2を2台ずつ置いている場合。

耐障害性のある例だと

AZ2つに、4台ずつ置いている場合。

一般的に耐障害性が上がるとコストが上がるということがある。

もう1つの例だと、

AZ3つに、2台ずつ置く例。

これはコストを抑えられている。ただ、複雑さはある。

 

可用性の実現

  • 複数のAZおよびリージョンを使用する
  • 可用性の高いサービスを使う。
  • Multi-AZ Amazon RDS : 2つの AZ でレプリケーション
  • S3 : 異なる AZ に複数のコピーを保存
  • ELB : LB クラスターを提供
  • SQS : メッセージングクラスター
  • Dynamo DB ：
    同じリージョンの複数の AZ 感でデータを自動的に同期してレプリケートする。
    施設規模で障害が発生してもデータを保護することができる。
  • Route 53 :DNSクエリに対する応答に失敗したことがない。

耐障害性の実現

  • Dynamo DB : 同上
  • Route 53 : 同上

 

練習問題

現在使用しているWebサービスのパフォーマンス SLA は、1秒未満でリクエストに応答するというもおです。
通常の運用でも高負荷な運用でも、4つのインスタンスにリクエストを分散することでこの SLA を達成しています。
1つの AZ が利用不可能になった場合、サービスの高可用性と耐障害性を確保できるのは次のどのアーキテクチャですか？

 

選択肢

1: 1つの AZ の4つのサーバーにサービスをデプロイする。

2: 1つの AZ の6つのサーバーにサービスをデプロイする。

3: 2つの AZ にまたがる4つのサーバーにサービスをデプロイする。

4: 2つの AZ にまたがる8つのサーバーにサービスをデプロイする。

 

解答
4

 

解説

1: 単一のAZなので違う

2: 単一のAZなので違う

3: 1つの AZ に対してインスタンスが2つだけでは SLA を満たさないので違う。

原則3つ目

「融通の聞く実装」

クラウドのメリットとしては、必要な時に生成して、不必要な時に削除するということ

固定IPアドレスが必要な構成にしないこと。（アンチパターン）

固定的なIPアドレスが必要な場合には付け替え可能なEIPを用いよう。

 

ELBを配置することで

背景にあるシステムに融通が聞く。

auto scalingを設定する。

これにより、適切なec2インスタンスの数を保持することができる。

 

自在に再起動できる設計を使用する

  • ステートフルではなく、ステートレスに。
    セッションデータを DynamoDBに保存するなど
  • ELB と Cloud Watach を使用して、インスタンスの健全性を調べる。
  • ブートストラップ
    ユーザデータやアプリケーションを、マシン起動時にインストールするようにするとよい。
    可能であれば、構成やカスタマイズ設定をインスタンス外に保存
  • S3にアプリケーションを置いて起き、ユーザデータ処理で配置など
    セッションデータなどを別レイヤ（RDS）などに保存するようにすれば、
    EC2が増えたとしても同じ値が取得できる。

 

練習問題

ある携帯電話会社が、動的コンテンツを使ってコンテストのテレビコマーシャルを放送しています。
この会社は、コマーシャルが放送された後のウェブサイトのトラフィックの急増に対応したいと考えています。
ウェブサイトは対話型で、訪問者の所在地、購入履歴、現在放送中のコマーシャルに応じてカスタマイズされたコンテンツが表示されます。
Auto Scaling を設定して需要の急増に応じてスケールアウトし、同時に需要の少ない時間のコストを最小化できる
アーキテクチャはどれですか？

 

選択肢

1: スケールアウトしなくても高いトラフィックボリュームに対応できるような最小サイズを持つ、
Auto Scaling グループを設定する。

2: トラフィック負荷のピークに対応できる大規模な Auto Scaling Group を作成し、
一部のインスタンスを停止する。停止したインスタンスを使用してトラフィックが増加したときに
スケールアウトするように Auto Scaling Group を設定し、新しいキャパシティーがすぐにオンラインになるようにする。

3: Cloud Front と S3 を使用して静的コンテンツを保存する。トラフィックの増加に合わせて
スケールアウトするように Auto Scaling を設定する。事前設定された AMI から新しいインスタンスを起動し、
起動時にユーザデータを渡すようにし、起動設定を行う。

4: Auto Scaling グループをオリジンとして設定し、Cloud Front と S3 を使用して変化するコンテンツをキャッシュする。
Auto Scaling を設定して、最初に Cloud Front と ElastiCache にキャッシュを追加するのに
必要な数のインスタンスを起動し、キャッシュが完全に追加されたらスケールインする。

 

解答
3

 

解説

1: 常にトラフィックのピークに合わせてプロビジョニングするため、コストがかかりすぎる。

2: Auto Scalingの仕組みは、あらかじめ停止したインスタンスを用意するというものではなく

新しい EC2 インスタンスを生成したり削除したりするということ

4 : 動的コンテンツの配信に対応していないので違う

 

練習問題

3つの AZ (us-east-1 a, us-east-1 b, us-east-1 c)の us-east-1で稼働しているアプリケーションがあります。
このアプリケーションは、通常9つの EC2インスタンス を実行する必要がありますが、
AZ が利用できなくなった場合に、 Auto Scaling が代替インスタンスを残りの AZ で起動しているあいだは
65% 以上のキャパシティーで実行できます。
このアプリケーションに最も高い可用性を実現できるインスタンスのデプロイ方法はどれですか？

 

選択肢

1: アプリケーションを us-east-1 a の4つのサーバー、 us-east-1 bの5つのサーバーにデプロイし、

予備として us-east-1 a に停止したインスタンスを5つ用意する。

2: アプリケーションを us-east-1 a, us-east-1 b, us-east-1 c それぞれ3つのサーバーにデプロイする。

3: アプリケーションを us-east-1 b の6つのサーバー、 us-east-1 c の3つのサーバーにデプロイする。

4: アプリケーションを us-east-1 b の9つのサーバーにデプロイし、予備として us-east-1 aに停止した
サーバーを9つ用意する。

 

解答
2

 

解説

1: Auto Scaling は停止したインスタンスを起動しない

3: 2bが利用できなくなった場合、停止率が66%となる。

4 bで停止した場合に、100%停止してしまうのでだめ。

分野2：実装/デプロイ

10%の出題

全員が開発者である必要はない。

コードで自動化ができる

 

分野1（可溶性、コスト効率、スケーラブルなシステムの設計）では、何を使用するか（what）に焦点をあてた

分野2（実装：デプロイ）では、どう使用するか（How）に焦点をあてる

howに焦点を当てているので、より実践的な内容が出題される。

 

細かい機能を把握するには、実際に触ってみるのをおすすめする。

 

現在 100 ほどのサービスがあるが、

全部を学ぶのは現実てきでなないので重点的に勉強しよう。

重点的とは？

  • コンピューティングとネットワーク
    EC2, VPC
  • ストレージ
    S3, Amazon Glacier
  • DB
    RDS

上記3つはほぼ多くのビジネスパターンで必要になってくるため重要

  • デプロイメント
    CloudFormation, Cloud Watch, IAM

これは運用していくなかで必要

  • アプリケーションサービス
    SQS, SNS

これは疎結合な運用をするために必要

「コンピューティングとネットワーキング」

EC2のオンデマンド、リザーブドインスタンス、スポットインスタンスの違い、HW専有インスタンスとは何か？を理解しよう。

EBSルートとインスタンスストアルートの比較

メタデータとユーザデータを使用したブーとストラップ

※ユーザデータとは、起動時に与えられるデータ。
これをつかってブートストラップする内容も押さえておこう

EC2に連携するサービス

  • ELB
    AZはまたげるが、リージョンはまたげない。など抑えておこう
  • Aout Scaling
  • EBS
    スナップショットやEBS最適化されたEC2の利用など
  • VPC
    IPアドレッシング。セキュリティグループ関連など。

 

問題の中で、IPレンジはCIDR表記で使用するため、読めるようになっておこう。

設計上の推奨としては、2つのAZにそれぞれpublicとprivateのサブネットを作成する。

同じVPC内のEC2はプライベートIPを使ってアクセスできる

IPアドレスを関連ずける方法は、生成時に紐づける方法と、起動後に紐づける方法がある。

 

練習問題

EC2 インスタンスが起動され、EIP がそのインスタンスに関連づけられています。
そのEC2インスタンスで実行されているアプリケーションは、どのようにインスタンスの
新しい Public DNS 名を判断できますか？

 

選択肢

1: OSレベルの hostname コマンドを使用する。

2: EC2インスタンスのメタデータをクエリする。

3: 該当する Cloud Watch のメトリックスをクエリする。

4: EC2インスタンスのユーザデータをクエリする。

 

解答
2

 

解説

1: public nat の名前を引くことができない。

3: ホスト名はメトリックスではない。メトリックスとは常に変化するメトリックスなどを記録するもの。

4: ユーザデータはブートストラップ時の情報など。

「ストレージとコンテンツ配信」

S3 と Clacier の違いを把握しておかなければならない。

S3は

  • 結果を確認する整合性モデルであるということ
  • ストレージにクラスがあるということ

Clacier

  • S3は必要なときにすぐにデータを取り出せるのに対しGlacier は時間がかかる。
    これはオプションによって異なる。
  • S3での暗号化はサーバサイド暗号化のオプションが設定できる
    Gracierは全てのデータが暗号化される。

RDS

重要なポイント

フェイルオーバー時は IP アドレスが変わるので、DNS名を使用しよう

ユーザが指定した時間にバックアップが行われているよ

また、そのときにスナップショットを取っていて、それをもとに復元されるよ

復元の際は、上書きされるのではなく、新しいインスタンスが生成されるよ。

 

練習問題

プライマリの DB インスタンスで障害が発生した場合、RDS Multi-AZ 配置はどうなりますか？
（3つ選択してください）

1: オリジナルのプライマリ DB インスタンスが再起動し、新しいスタンバイレプリカになる。

2: オリジナルのプライマリ DB インスタンスは削除され、新しいスタンバイレプリカが作成される。

3: DB インスタンスの DNS レコードが変更されて、新しいプライマリを指定する。

4: スタンバイの DB インスタンスがオリジナルのプライマリ IP アドレスを引き継ぐ。

5: 別の AZ のスタンバイのレプリカが新しいプライマリに「昇格」する。

6: 直近のバックアップから新しいプライマリ DB インスタンスが作成される。

 

解答
2,3,5

 

解説

この問題はフェイルオーバー時の問題。

1: オリジナルのプライマリは削除される。RDSでは、障害の要因に関わらず、すぐにセカンダリが昇格する。

4: RDS は IP アドレスではなく、 DNS 名を使用する。
ほとんどのAWSサービスでは、ベストプラクティスを採用しており、DNSを利用することを覚えておこう

6: Multi-AZ RDS はレプリケーションとフェイルオーバーを使用する。

 

ここで問題を解くときに注意することが、フェイルオーバー時の処理が

選択肢の順番になっているとは限らないということ

 

順番にならべると

5 -> 3 -> 2の順番で処理が行われる。

デプロイメントとマネジメント

  • Cloud Formation
    EC2のブートストラップなども実行ができる。
  • Cloud Watch
    クラウドリソースとアプリケーションを監視

組み込みメトリックスとカスタムメトリックスの違いを把握しておこう

アラームと Auto Scaling

IAM

IAMロールなどを把握しておこう

 

アプリケーションサービス

  • SQS
    テキストのみのメッセージをやりとりできるポーリングモデルと、名前つきキュー

非同期ワークキュー

  • SNS
    Pub-Sub（プッシュ）モデル、名前付きトピック
    送信メカニズム：HTTP/HTTPS、SQS、SMS、メール

SNS を Cloud Watch アラームと連携

この2つはメッセージングサービスである。

メッセージングサービスは、疎結合を実現するのに役立つ。

まとめ

  • 重要で、よく利用されているサービスに焦点を当てる。
  • 各サービスについて以下を実施する。
    → 基本的なユースケースとパターンを把握
    → サービスの仕組みと使用方法を把握
    → 実践での経験を積む
  • 暗記しない：試験に求められるのは機械的な暗記力ではなく、応用力です。

分野3：データセキュリティ

重要なことは、レイヤーごとにセキュリティを設定するということ

各レイヤーでどのようにセキュリティを設定するのかを把握しよう。

 

4つのレイヤー

  • インフラストラクチャーレイヤー
  • コンピューティング/ネットワークアーキテクチャレイヤー
  • データレイヤー
  • アプリケーションレイヤー

 

「インフラストラクチャー」で重要なこと

責任共有モデル

→お客さんとAWSで担保しなければならない責任範囲が別れているということ

→試験でも、どのように責任範囲が別れているのかが出題される。

 

AWS リソースの保護

→ 最小権限の原則

→ アイデンティティ

各ユーザまたはプロセスの権限は、実行する必要があるアクティビティに限られる。

  • ユーザまたはプロセスの権限はアイデンティティで示される。
  • AWS API にアクセスできるアイデンティティは3種類
    → 「マスターアカウント」
    最初のメールアドレスによって設定されるアカウント
    乗っ取られたら被害がすごいので多要素認証を設定しよう。
    そのアカウント全体に対する完全な権限を持っている。
    制限できない。

MFAの追加をしよう。

ベストプラクティスは、このアカウントをアイデンティティに使わないことです。

  •  IAMユーザ
    グループやポリシーによる詳細なアクセスコントロール
  • AWSコンソール / CLI / API アクセスをコントロール
    → Security Token Service(STS)/フェデレーション

「STS / フェデレーション」

おそらく理解するのがもっとも難しい仕組みが STS です。

STSを使用すると、

一時的な権限を付与することができる。

※フェデレーションとは
→ AWS とか別の、例えば社内で許可を得た人だけがアクセスできるような仕組みのこと

 

練習問題

会社の AWS アカウント管理者が今日退職しました。
この管理者は、マスターアカウントとパーソナル IAM 管理者アカウントに対するアクセス権を持っていました。
これらのアカウントを使って、この管理者は別の IAM アカウントとキーを生成しました。
会社の AWS インフラストラクチャを保護するために今すぐに実行する必要があることは、
次のうちどれでしょうか？（3つ選択してください。）

 

選択肢

1: パスワードを変更し、マスターアカウントに MFA を追加する。

2: マスターアカウントによるログインに IP 制限をかける

3: キーを交換して、 IAM アカウントのパスワードを変更する。

4: IAM アカウントを全て削除する。

5: 管理者の IAM アカウントを削除する。

6: 全ての EC2 インスタンスを新しいロールで再起動する。

 

解答
1,3,5

 

解説

2: マスターアカウントは一切制限をすることはできません

4: デメリットが大きすぎるので、そこまでの必要はない。

6: ロールはSTSに基づいているため、元社員が認証情報を引き続き持っているわけではない。

「コンピューティング/ネットワークアーキテクチャの保護」

サブネットの役割は

vpcをさらに細かい IP アドレスの範囲に区切るということ。

SGとNACLの比較

この2つの違いを把握しよう

ほとんどの場合はSGで対応できるが、許可の仕方だけが違う。

NACLでは、ホワイトリスト方式なので、

特定の CIDR 範囲からのアクセスを拒否することができる。

「インターネットゲートウェイ、仮想プライベートゲートウェイ、Direct Connect」

VPC にトラフィックを出し入れするサービス

それぞれのユースケースを把握

  • IGW: インターネットに接続
  • VGW: VPNに接続
  • Direct Connnect: インターネットを使わずに、AWSとオンプレミスの環境を繋ぐ専用線接続
  • VPC ピアリング: 他のVPCに接続

「ルートテーブル」

通信の経路を設定するために使われる。

サブネットと関連づけられる。

IP範囲の宛先を定義

  • ローカルルールはデフォルトで定義
  • インターネット（パブリックサブネット）にアクセスするための IGW へのルート
  • オンプレミスネットワークにアクセスするための仮想プライベートGWへのルート
  • ピアリングされた VPC にアクセスするためのピアリング接続へのルート

ルートテーブルの際に意識しないといけないのが

VPC の外と中で通信をしたいときの設定。

 

練習問題

あなたは VPC 内のサブネットにインスタンスをデプロイしました。
S3 へのアクセスを許可する手順で、正しいのは次のどれでしょうか？

1: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
ACL のアウトバウンドルールでポート443 を開放をする。インスタンスに　EIP を追加する。

2: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。SGのアウトバウンドルールで443 を開放する。インスタンスに EIP を追加する。

3: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
SGのアウトバウンドルールでポート443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

4: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
SGのアウトバウンドルールでポート 443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

5: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。ACL のアウトバウンドルールでポート443 を開放をする。インスタンスに　EIP を追加する。

6: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。SGのアウトバウンドルールでポート 443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

 

解答
2

 

解説
S3への経路で、仮想プライベートゲートウェイを使うことはありません。
そのため、1,3,4が除外できる。
ACLでは除外するためのアクセスのみ設定できるので、
アウトバウンドとインバウンドが設定できなければいけない。
そのため、5が除外できる。
IP アドレスは、EIPを使うので、 6が除外できる。

「データレイヤー」

データを保護する方法としては4つある

  • 転送中のデータ
    • AWS の入口と出口
    • AWS の内部
  • 保管時のデータ
    • S3
    • EBS

主要なストレージサービスである、EBS と S3 を見ていこう

転送中のデータ

AWS インフラストラクチャへのデータ送信と、AWS インフラストラクチャからのデータ送信

  • ウェブ経由のSSL
  • IPSec 用 VPN
  • 直接接続
  • インポート/エクスポート

AWS API に送信されるデータ

  • AWS API 呼び出しはすべて、HTTPS REST 呼び出しです。

S3 に保管中のデータ

アクセス

  • IAM ポリシー
  • バケットポリシー
  • アクセスコントロールリスト
  • 一時認証情報
    • 署名つき URL に使用

暗号化

  • サーバ側（AWS が管理するキー）
  • サーバ側（お客様が管理するキー）
  • クライアント側
  • クライアントコードの暗号化 / 復号化
  • キーは S3 から独立した形でお客様が管理する。

「EBS に保管中のデータ」

  • 暗号化された EBS ボリューム（AWS が管理するキー）
  • EBS ボリューム上の暗号化されたファイルシステム

（お客様が管理するキー）

  • アプリケーションレベルで暗号化されたデータ
    • クライアント側にあるアプリケーションの暗号化 / 復号化データ
    • お客様が管理するキー
    • サードパーティの支援
      （例えば、一部のDBテクノロジーで使われてる Transparent Data Encryption（TDE））

EBS はインターネットにアクセスしないので、

インターネットに対するアクセスはアプリケーションの話になります。

 

練習問題

あなたの会社には機密情報があり、セキュリティポリシーにしたがってこの情報を暗号化形式で
保存しなければなりません。暗号化機能を提供するサービスは、次のどれですか？
（3つ選択してください）

1: EBSボリューム

2: S3

3: EC2 インスタンスストレージボリューム

4: RedShift

5: DynamoDB

6: ElastiCache

 

解答
1,2,4

 

解説
3,5,6には暗号化機能がない。

※ただし、この問題では補足が必要
5は、2018年に暗号化機能が追加された。

アプリケーションレイヤー

責任共有モデルでは、お客様が責任をおうことになっている。

「それぞれのアイデンティティによって、何を保護しているのかを把握しよう。」

  • IAM
  • OS/AD/LDAPアカウント
  • アプリケーションアカウント
  • アプリケーションの保護（オンプレミスと同様）
    安全なパスワードストレージとパスワードポリシーを使用する。

OSをip tableなどで保護したり、ソフトウェアをアップデートしたりする

堅牢なロールベースアクセスコントロール（RBAC）を使用する。

 

練習問題

IAMポリシーでコントロールできるアクションは、次のうちどれですか？
（3つ選択してください）

1: RDS データベーステーブルを作成する。

2: VPC SG を構成する。

3: .NET アプリケーションにログインする。

4: RDS データベースを作成する。

5: S3 バケットを作成する。

 

解答
2,4,5

 

解説
1: DB管理者の管理になる。IAMで制御できるのは RDS の作成。

3: アプリケーションのセキュリティになる。

4: 正解。1との違いは、RDSインスタンスを操作するので正解。1は、DBエンジン内の操作になるので違う。

 

練習問題

ウェブ層のインスタンス（ウェブ層の SG を共有する別のサブネットのインスタンスグループ）
からのみ HTTP トラフィックを受け入れるアプリケーション層サブネットに、
EC2 インスタンスのグループを作成しようとしています。
これを実現する方法として正しいのは次のどれですか？

 

選択肢

1: アプリケーション層インスタンスの手前の SG を LB に追加する。

2: アプリケーション層の各インスタンスを、ウェブ層 SG からのインバウンド
HTTP トラフィックを許可する SG と関連づける。

3: ウェブ層サブネット IP 範囲からのインバウンド HTTP トラフィックを許可するアプリケーション層サブネットに、ACL を許可する。

4: IPアドレスに基づくアプリケーション層インスタンスにトラフィックを送信するために、
ウェブ層サブネットのルーティングテーブルを変更する。

 

解答
2

 

解説

1: ロードバランサーでは、レイヤー感でのトラフィックをコントロールできない。

3: 注目すべき点は、ACLはステートレスな操作になるので、アウトバウンドも設定しないといけない。

4: ルートテーブルはトラフィックを送信するが、ブロックはしない。

 

練習問題

公開ウェブアプリケーションがあり、ユーザが自分で登録してアカウント作成することになっています。
このアカウントは、アプリケーションの認証ユーザと静的オブジェクトを共有します。
そこで、このコンテンツを S3 に保存して、適切に権限を付与されたユーザだけがウェブ経由で
利用できるようにしたいと思います。これを実現する方法として、最もコスト効率が良く、パフォーマンス
に優れているのは次のどれですか？

 

選択肢

1: バケットポリシーでバケットにアクセス権を付与する。

2: ウェブサーバから、オブジェクトへの一時アクセス権付きの署名済み URL を返す。

3: IAM ポリシーでオブジェクトへのアクセス権を付与する。

4: ユーザのブラウザーに配信するために S3 からオブジェクトを読み出すウェブサーバコードを作成する

 

解答
2

 

解説

1: 公開ユーザは IAM ユーザを持っていない。IAM は AWS インフラストラクチャを保護するが、アプリケーショは保護しない。

3: アプリケーションユーザは AWS アカウントを持っていない。

4: ウェブサーバーコードというのは、起動したウェブサーバー経友でアクセスするということ。これでも実現できないことはないが、
EC2インスタンス経友で起動するというステップが増えている。またEC2は帯域幅が小さいので遅くなる。またEC2も起動しているので、コストもかかる。

分野4:一般的なトラブルシューティングの情報および質問に関する問題

  • EC2インスタンスの接続
    • ec2にsshできないなどの問題
    • ec2が起動しないなどの問題
  • EC2 インスタンス、EBS ボリューム回復
  • AWS サービス制限の問題

「接続のトラブルシューティング」

ゲートウェイがアタッチされているか。

IGW VGW など、ゲートウェイの種類を把握しよう。

ルートテーブルをきちんと設定しないといけない

ポートに設定できるか問題：これはSGなどの設定などを把握しよう。

 

接続できないのにはいくつかの原因が考えられる。

VPC の外部から VPC 内のインスタンスまで：

  • アタッチされた GW （IGW または VGW）
  • 企業ネットワークから VPC までのルーティングルール
  • VPC またはサブネットのルートテーブル
  • インスタンスの EIP または　パブリックIP
  • NACL
  • SG
  • OS レベルのファイアウォール

問題になるのは、あるケースで EC2 に接続できないという状況です

4つのポイントがあります。

  1.  IGW
  2. SG, NACL
  3. EIPが関連づけられているか
  4. ネットワーク経路の話
    →　public サブネットのルートテーブルに、IGWが設定されていることが必要。

「インスタンス/EBS ボリューム回復のトラブルシューティング」

  • EC2 インスタンスが応答しなくなることがある
    ex. 例えば、Linux のカーネルパラメータに変な値を設定してしまったとか
    アタッチしているEBSボリュームはデタッチできる
    →　必要なら強制的にでタッチ
  • EBS ボリュームを正常なインスタンスに再アタッチする。
  • 以下のプロセスを実行して非稼動ブートボリュームを回復する。
    • ボリュームをでタッチ
    • データボリュームとしてアタッチ
    • ファイル内の問題を解決
    • 元のインスタンスに再アタッチして、再起動

「制限問題のトラブルシューティング」

AWS には様々なソフトリミットがあある。

また、いくつかのハードリミットもある

制限は相互に影響を及ぼすことがある

  • EBS の制限に達したために、 EC2 インスタンスを起動できないことがある。
  • Trusted Adviser が役立つ

一般的な制限は次の通り（基本的には全てリージョンごと）

  • アカウントごとのインスタンス数は 20 まで
    （インスタンスタイプによってはさらに少ない場合がある）
  • リージョンごとの EIP は 5 まで
  • VPC ごとの SG の数は 500 まで
  • LB は 20 まで
  • Auto Scaling グループは 20 まで
  • EBS: 5,000 ボリューム、10,000 スナップショット、40,000 IOSP、20 TBのストレージ
  • S3 のバケット数は 100 まで。
  • ネットワークの帯域幅
  • etc…

 

問題を解く際に、制限のないようを記憶する必要はない。

  • 制限があることと、その制限によって生じる問題について注意が必要
  • 制限の引き上げを要求する方法について把握する。
    →　ソフトリミットは、設定により変更できることがある。

 

練習問題

EBS-Backed EC2 インスタンスに障害が発生し、応答しなくなりました。
ルートボリュームに重要情報が入っているために復旧する必要がありますが、
あらゆる手段を試みてもインスタンスにログインできません。
元の AMI にはアクセスできますが、ルートボリュームの最新のバックアップが利用できません。
どうすればボリューム内の情報を復旧できますか？

 

解答
4

 

解説

1: デフォルトの設定では、インスタンスの削除と同時に、ルートボリュームも削除されてしまう。

設定でそうならないこともできるが、この問題ではそれが書いていないので、消えてしまう。

2: スナップショットからインスタンスは起動できない。起動は AMI からのみ可能。

3: 元の AMI には障害が発生したデータと同じデータは存在せず、同一データではないため間違い。

 

練習問題

VPC パブリックサブネットにアプリケーションをデプロイしました。
複数の同じ EC2 アプリケーションインスタンスが正常に稼動し、
インターネット経由でアクセスできます。
ここで、同じ AMI および SG を使用して、同じサブネットに新たな EC2 インスタンスを起動し、
アプリケーションをスケールすることにしました。
ところが、新しいインスタンスにはインターネットからアクセスできないことが分かりました。
どこに変更すれば、新しいインスタンスにインターネットからアクセスできるようになりますか？

 

選択肢

1: パブリックサブネット内にNATインスタンスをデプロイする。

2: 新しいインスタンスのゲスト OS に、パブリックIPアドレスを設定する。

3: EIP を新しいインスタンスに割り当てる。

4: サブネットのルートテーブルを、新しいインスタンスへのアクセスを許可するように変更する。

 

解答
3

 

解説

1: パブリックサブネット内のインスタンスが NAT インスタンスを使う必要はない。
windowファイアウォールがRDPをブロックすることはあるが、この場合、AMI から作られれているので、許可されているはず。
パブリックサブネット内のインスタンスは、EIPによって接続ができる。

2: ルーティングルールによって、ポートのトラフィックまでは制限できない。
ホスト　OS が知っているのはプライベートIPのみ。パブリックIPはOSが知らない情報。

4: ルートテーブルはサブネット全体に適用され、サブネット内の他のインスタンスは正常。
また、デフォルトでは全て許可されている。
ルートテーブルの問題ではないことが、問題文からわかる。

この問題のポイントは
SGは、デフォルトでは、全てのインバウンドは許可されていないということ
なので、つなげたかったら許可しないといけないということ。

まとめと今後について

実際に触って実務経験があることが重要。

試験の準備

詳細

https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

トレーニング

  • セルフペースラボ
    https://aws.amazon.com/jp/training/self-paced-labs/

コース
https://aws.amazon.com/jp/training/course-descriptions/

参考資料

  • ホワイトペーパー
    https://aws.amazon.com/jp/whitepapers/
  • アーキテクチャセンター
    https://aws.amazon.com/jp/architecture/
  • ドキュメント
    https://aws.amazon.com/jp/documentation/

試験ガイド
https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate_Exam%20Guide_v1.5_FINALJP.pdf

サンプル試験
https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate_Exam%20Sample_v1.5_FINALJP.pdf

模擬試験
https://aws.amazon.com/jp/training/

個々のサービスを詳しく学びたい場合

  • AWSクラウドサービス活用資料集
    https://aws.amazon.com/jp/aws-jp-introduction/

試験の登録
https://aws.amazon.com/jp/training/

認定FAQ
https://aws.amazon.com/jp/certification/faqs/

Androidエンジニア デザイン部 #2に行ってきました

gTUjFXqCGAwr コメントをする

Androidエンジニア デザイン部 #2

https://nohana.connpass.com/event/94621/

に行ってきたので、そのときのレポートブログ

LT1つ目：InvisionのAndroidアプリでみる4つのデザイン基本原則

エウレカのFutagawaさん

資料

以下、LTを聴きながらのメモ

今日話す内容

  • Invisionとは
  • 4つのデザイン原則とは

Invisionとは

モックでデザインを簡単に作れるやつ

4つの原則とは

  • Proximity：近接
  • Repetition：反復
  • Alignment：整列
  • Contrast：コントラスト

「Proximity：近接」

グループ化した要素は近くに、そうじゃない要素はより遠くに

まとまりある要素同士の距離は、まとまりのない要素同士の距離よりも短くする。

「Alignment：整列」

画面内の全ての要素が他の要素と視覚的なつながりをもつようにする。

「Repetition：反復」

アプリの全体を通してなにかの特徴を繰り返す。

「Contrast：コントラスト」

同じ要素でないものははっきりと異ならせる。

例えば、タイトルとアップデート時間は全くことなるものなので

文字の濃さを変えたりする。

 

ノンデザイナーズ・デザインブック

https://book.mynavi.jp/ec/products/detail/id=22176

非デザイナーでも読みやすい。

たまにPDFを配ってるときとかもある。

LT2つ目：「ありがたいUI」をもっと大事にしたい。

資料

以下、LTを聴きながらのメモ

 

デザインに対する持論

デザインって広義的な意味でいっぱいあるが

大切にしたいと思っていることがある。

デザインって、かっこいいとか美しいとかクールと思われがちだ。

かっこいいからインストールするとか、そういう訴求力もあるが

かっこいいから使い続けてるとかはあまりない。

使い続ける理由としてかっこいいからというのはあまりない。

※ただし、アイコンは除く

 

ありがたいと思えるアプリ

twitterの画像表示がありがたい。

複数枚あるとスライドできるが、

消したいときは、下から上にスワイプする。

これの嬉しいところが、タイムラインを眺める動作と変わりない動作でできる。

これがもし、画面上のほうに×ボタンとかで閉じる UI だったら、少し手間になる。

CamScannerの画像切り抜き

タップ部分が拡大表示される。細かく調整ができる。

座標の調整が確認しやすい。

マルチウィンドウ対応アプリ

例えばyoutubeをバックグラウンド再生できる。

AbemaTVのCM中にtwitterみるとか、そういうことができる。

 

これらのアプリにある機能がありがたいので

他のアプリに乗り換えられない。

クールとか美しいアプリというのも大切だが、

ありがたいUIも大切。

LT3つ目：Google I/O 2018

Googleの方のLT

自社アプリ、IOSched について。

 

IOSchedは、

Androidアプリを作っている人に、リファレンスとして見てもらえるように作られている。

 

2018年の見所

  • 秘伝のたれのソースコードをフルスクラッチ
  • Kotlin
  • Architecture Component

UIの面でもベストプラクティスをやろうとしている。

マテリアルデザインで出したい。

だが、I/Oがあるまではマテリアルデザインで出せない。というジレンマがあった。

なので、デザインを2つ作った。

 

今年の見所

Lottieというアニメーションのライブラリを使っている。

カウントダウンを実装している。

githubにソースコード公開しているので、DLしてぜひ見て見てね。

 

ナビゲーション

去年まではナビゲーションペインで作っていたのだが

ナビゲーションボトムに切り替えた。

view pager

1つのviewはマテリアルデザインでいうところの1つの要素

なので、viewとviewの間には区切りが欲しい。

いろんなアプリはその区切りを入れてないので、入れることによりくっきり見える。

ボトムアップバー

これもライブラリの中に入っている。

ここはアクションのメニューを並べる。

fabが据えられる位置を決められる。

たとえばGmailみたいなアプリで、詳細画面に行ったときは返信するボタンになるとかで、

返信ボタンは左に出したいとかだったら、アニメーションを使う。

スナックバー

これまではfabを押し上げるような形だったが、

fabの上に出しましょうとしている。

ボトムシート

一時的な状態を出すのにすごくいい。

必須要素をぜひ知っていただきたい。

 

Googleのアプリをだすときにクリアしなければいけないこと

  • タッチフィードバック
  • 色のコントラスト。背景と文字のコントラストが十分かどうか？
    accesibility checkerというアプリで、チェックできる。
  • 色だけで情報を表さない。必ず文字も入れる。色弱の人がわからないので。
  • 前の画面ってなんだっけ？とならないようにアニメーションをつけるようにする。
  • talkbackでの動作

LT4つ目：Kyashはなぜ使いやすいのか

ノハナの方のLT

資料

以下、LTを聞きながらのメモ

 

今回のアンケート（connpassの参加フォームで「UIが好きなアプリは？」という質問があった）でも、

Kyashが一番評価がよかった。

1. シンプル

Navigation Drawerがない。

  • 機能が絞れている。
    我々は、多機能にしがちだが、Kyashは機能が絞られててよい。
  • 階層が浅い
    画面スタックが最大でも3階層
    人間は画面について覚えにくいが、3階層しかないので覚えやすい。
  • 画面内の要素が多くない

これらのこと = アプリで迷子になりにくい。

2. 操作感のあるUI

請求画面と送金画面が大体似ているが、

画面の下の操作が少し違う。

 

画面遷移

下から出てきて、前の画面が消えるようになっている。

横スライドで画面が変わったりもする。

画面の連続性を出すためにいい。

3. こだわり

39円を送ると、thank you というアニメーションが出る。

一見意味ないことのように思える（これでユーザ数が増えるとか思えない）が、こだわりがあってよい。

ギフトコードの画面についても、細かいアニメーション（プレゼントボックスがカタカタ動く）がある。

これも意味ないと思うが、こういったこだわりのアニメーションを実装したりすることで、

ファンが楽しくなって、ファンが増えていく。

以下、懇親会で周りの人と喋ってて知ったこと

  • https://material.io
    マテリアルデザインについて書かれている。
  • なるほどデザイン
    初心者向けのデザインの本。読みやすい
    https://www.amazon.co.jp/dp/B012VJNW6Q/
  • Xamarin
    Android, iOSアプリどちらも一度に作れる
  • Human Interface Guidelines
    iOSアプリを作るときのデザインのガイドライン