[AWS] IAMユーザで請求情報を確認する

AWSの請求画面を表示するには、デフォルトの設定だと

root でログインしなければ見ることができません。

今回は IAM ユーザでログインして請求画面を表示させる方法を書きます。

公式ドキュメント

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.html

 

IAM ユーザで請求画面を表示させるには、次の 2 つの設定が必要になります。

  • root でログインし、請求画面を IAM ユーザにも表示させるように設定
  • IAM ユーザに、請求画面を表示させるポリシーをアタッチ

 

root でログインし、請求画面を IAM ユーザにも表示させる設定

root でログインし、右上のバーからアカウントを開きます。

画面をスクロールし、「IAM ユーザ/ロールによる請求情報へのアクセス」を開き

「IAM アクセスのアクティブ化」にチェックを入れ「更新」します。

IAM ユーザに、請求画面を表示させるポリシーをアタッチ

請求画面を表示させたい IAM を選択し、

「Billing」のポリシーをアタッチします。

これで請求情報の全て(請求書 や 予算 など)が表示できるようになります。

個別に許可したい場合は、下記のドキュメントを参考に個別にポリシーを付与しましょう。

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html

IAM ユーザでログインしなおし、請求画面を開くと問題なく表示ができました。

 

チャリを車に積む

イベントに行くためにチャリを車に積んだときの知見です。

レンタカーを借りてチャリ2台を車内に積みました。

レンタカーは日本レンタカーで V-A クラスの車種にしました。

https://www.nipponrentacar.co.jp/service/truck/index.htm


まずは後部座席を倒します

乗せるために買ったものです。

  • 梱包材
    車を傷つけないためにチャリの下に敷きます
  • 自転車の荷紐
    チャリが倒れないようするために使います
  • テープ
    敷いた梱包材を止めるのに使います

梱包材を敷きます

後輪スタンドを車内に置きます。

前輪を外した状態でチャリを入れます

外した前輪と車体を荷紐で固定します。

この状態でこんな感じになります

もう一台も同様にして入れます(今回は1台目とは前後逆に入れました)

積んだ時のスペース感や荷物がどれくらい入るかの参考になれば幸いです。

この状態での前部座席は、普通に座れるくらいの余裕はあります。

チャリは間にもう一台積められそうですね(3人は座れませんが)

以前車中泊をした際には、一人は後部座席のチャリの間で寝て、

もう一人は前部座席を倒して寝ました。

【アーキテクチャ ディスカッション Vol.1】に行ってきました。

アーキテクチャ ディスカッション Vol.1

https://istyle.connpass.com/event/97862/

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

 

ディスカッション形式のメモです。
発言に対する発言を1つインデントするようにして書いています。

※正直、うまくまとめられている自信がないので、会話を追って雰囲気が伝われば幸いです。

 

ビジネスロジック層のモデリング

  • active record を使ったときのモデリングが難しい。どうモデリングをするかで分離の仕方が変わる。
    • DB を一回忘れるのはどうか?
    • DB のことは一旦忘れるけど、どこまでを考えるのかが重要になりそう。
    • それって DB を最初が存在している前提では?ソフトウェアの内部構造って、オブジェクトの意味やライフサイクル単位で作っていくと良いのでは?あまり、テーブルに引っ張られて考えるのはよくないかもしれない。
      • その分析ってどうやって始めます?
        • 業務フローから考えます。業務をプログラムに落とし込むにはどうしたらいいのかを考える。
        • この言葉はどういうカテゴリなんだろうとか。
          あまりプログラミングというか、サービス仕様だったりデータのカテゴリわけをする

          • この場合のデータってなんですか?
            • 仕様に出てくる言葉のこと。
            • モデリングっていう言葉の意味が幅広いので、焦点はここだよっていうのを考えるようにする。
            • エンジニアが使うことばっていうのはいろいろな意味があるので、その意味を付箋で貼ってみたりとかもする。
              部分部分でやっていかないといけない。業務の一番重要なところはどこなのかを聞いて、そこに焦点をあてるようにしている。

              • ドメインというのは、答えが出た時に、どういうことをやったんですか?
                • 僕らが行ったこととしては、経済活動という古くから使われているものをドメインとおくことにした。
                  入荷なのかなのかの単位を人それぞれだったが、少しずつリファクタリングすることで擦り合わせていった。
                  図書館アプリを練習で作ってみようとなった時に、
                  会社は貸し借りが大事なのか?いや、在庫管理が大事だ。となって、在庫管理をドメインとして初めて行った。

Clean Architecrue を採用した話

  • 最初始めたときは、どうしてもこの形にならなかった
    presenters を使わない人もいて、translater を使う人もいた。
    スクラップ  &  ビルドを繰り返して、最終的にはこの形になった。
    大事なのは UML 図だった。

    • entity はきっとトランザクション管理でもよいのだと思った。
      ヘキサゴナルアーキテクチャがきて、そのあとこの形になったと思っている。
      オニオンアーキテクチャはただ単にドメイン駆動設計のことを行っているだけなので、use case の部分。
      僕はこれ、浸透させるために教育させるのは無理だと思った。
      なので、ツールを作った。
      WEB のときは、 presenter のときはいらないと思った。
      非同期処理は contorller が返してくれたほうが都合がいいときが多い。
      なので、WEB の場合は presenter はいらないが、GUI ツールのときはいると思っ

      • 教育は諦めた的なことを言っていて、ツールを作ったという話があったが、
        こういう手順でやってねということをやると、考えずにやってしまう人が出てきそうだが、どう思うか?

        • ツール使った方が早くできるよ、というメリットを提示して納得してもらった。
          保守フェーズをやったことがないエンジニアって、伝わらないからつらい。運用する辛さが伝われば話も伝わる。
          そういう意味では、モノリシックで1000行ぐらいあるメソッドの保守とかしてもらったほうがいいかもですね笑(会場でも笑いが起こる)
  • presenter について最近本を読んでて思ったことがあるが、
    本では、presenter はテストしにくい部分とテストしやすい部分を分けましょう、という話が23章であった。
    その中では、 view はテストしにくいが、viewmodel まではまだテストできるという内容だった。
    プログラミング言語中で、日付オブジェクトというものを view に渡したときに
    文字列に変換しなければいけない。
    日付オブジェクトを文字列に変換するのが presenter
    その文字を活用するのが view という感じにしていたので、
    presenter は必要なのでは?と思った。

    • dto を使っていて、テストするので、そこは問題ではないと思った。
  • clean architecture に乗っ取ってるかを管理する CI ツール気になる。
    • それは取り組みをやっている。構文を解析してチェックするようにしている。
      java で gladle を使ってやっているが、導入も簡単なので良い。
      ドメインの依存すべき方向とは逆方向になっているときなど、そういうのはすぐに検知できる。

DB に入れるときに レポジトリって入れると思うが、何を引数に渡している?

  • DB の方は基本的にイベントを保存するようにしている。
    失敗談で、entity を渡すっていうようにしていたら、
    レポジトリの中で新しい entity が渡されたときに、古いものとの差分をとって DB にインサートとかしていたので、その管理がつらくてやめた。

    • 僕もentityというか集約をインサートしている。
      • それってentityとテーブルに差がない状態になる?
        • いや、差がある。
        • DDD のいいところが、イベントをインサートするとDBは肥大化するが、ドメインは綺麗に保てることができるのでそこがいいと思っている。

レポジトリにおいて、参照系と更新系で分けている人はいますか?

  • 参照系だとオーバーヘッドが大きいと思うが、参照系でもユースケース層もあったほうが便利だよねという面もあって、みなさんの事例を聞きたい。
    参照系と更新系を同じレポジトリで管理するか否か?ということ。

    • Clean Architecure の場合は、ユースケースがインターフェイスになるので、レポジトリ使わないパターンで行った。
      • レポジトリはそのまま経由させて、書くのは RDS を使って読むのは Elastic Search とかを使ったりもしている。
        • たしかに書くのは多くなる。DB の先って何年か後に違うのにしようという話が出てくるので、そういう風にしている。
        • 両方とも同じように扱いたいので、レイヤを挟まないようにしている。
          • 逆に、レイヤを分けるようにしている人いますか?
            • 挑戦はしている。ドメインを守りたいみたいな方向でそういう風にしている。
            • 読む先と書く先が違うからという理由があるが、
              キャッシュが落ちた場合って、DBに取りにいくと思うが
              そういう場合はインターフェイスは同じだが、中身は違うようにしている。

キャッシュって、みなさん(Clean Architectureの)図でいうとどこに入れていますか?

  • DB のところに入れている。
    ただ、ドメインをまたぐときに困る。

Clean Architecture って、人と会話するのが苦手な人にとっては苦痛かもしれない

  • 人と会話して、こっちの人は商品って言ってるけど、こっちでは違うことを言っていて、
    そこの分析をやるのが楽しい。
    逆にそこを分析してからでないとコードに落とし込めないと思う。

    • お金をもらって、人に本当に必要なものを作るためには、人と会話ができないといけない。

ドメイン駆動をやっていると、自分の言語がプログラムになってくるのでプログラムを英語で書くのが辛くなる。

  • 逆に日本語のローマ字で書くと良いと、結構読みやすくて良い。

Clean Architecture の本を読んで思ったが、実践に使うには大きなサービスでないとやりずらい。ただ、実際に手を動かさないと習得しずらい、みなさんはどのようにしていますか?

  • 教育を2週間、題材を用意してやってみた。
    すると、完璧に理解するのは難しくても、コピペすればなんとかできるという状態には持っていけた。
  • 個人的には、小さいサービスを作ってみて練習している。
    自分の中で鉄板のお題(RSSリーダーを作るみたいな)を作ってみるというのをやっている。

    • その時って実際に業務でやるときとのレベル感というのが出てきてしまうと思うが、
      どうやってその差分を埋めてますか?

      • 埋まらないですね。ただ、どうしても抑えておきたい部分(例えば例外ハンドリングの仕方とか)はやるようにしている。
  • うちの会社ではレビューで学んでもらうようにしてますね。小さい単位で業務を任せて、レビューして教えたりする。

Flux アーキテクチャって Clean Architecture に似てるって思った人います?

GUIを組んでるときに思ったんだが、形的に似ているなと思った。
そのとき思ったのが、サーバーを介さなければ同じ形になるのかな?と思った。
特に思った人がいないので、この話はやめます笑

ゲームアプリのエンジニアも Clean Architecture に興味あるらしいですよ。

  • ゲーム全体をそうするのはしんどいかもしれないが、一部分だけ Clean Architecture にしてテスト可能にするのは良いと思う。

みなさんどういった経緯で設計とかアーキテクチャに興味を持たれましたか?

  • 僕の場合は 13 年続くでかいサービスを一人で保守していて、そこでアーキテクチャが必要だと思うようになった。
  • 自分でクソコードを生み出して保守しきれなくなって、あるべき姿ってどんなんだろうと思ったのがきっかけ。
  • コアなモデルのほうに興味があったのが一つと、学生のときに設計やアーキテクチャの情報がたくさん入ってきたので、そこがきっかけ。
  • オブジェクト指向から始まって、すごい人が言ってるからいいものに違いないと思って勉強から入った。
  • DBに興味がもともとあった。データモデルが出発点になって、それがきっかけ。
  • 入社したときに、Android が世に出たときくらいだった。一番最初の Activity に何千行もあるアプリを保守しなければいけなくなった。
    そこをどうにかしなきゃねって思って、アーキテクトの考え方になって言った。保守しやすいアプリケーションを突き詰めたら、今に至った。
  • 炎上しているPJがあって、どうにかしてくれというふわっとしたオーダーがあった。
    そういうもののセオリーってテストを書いて始めていくのだが、どうせだからドメイン駆動設計(というのがあるらしいレベルだった)を突っ込んでみたのがきっかけ。
    炎上PJってもしかしたらチャンス(新しいことに取り組める)なのかなと思った。
  • 他者が作ったが放り出したものと同じものを作ってくれと言われた。
    それが、ループが17段あったりもした。
    そういう過酷な状況の中で生き残るためには設計が必要だと思った。
  • 会社が、一人で作って一人で運用している人が多く、アーキテクチャを知っていないと自爆してしまうことがあるので、それがきっかけになった。

分析系の処理を書く(マイクロn秒)ときには、Clean Architecture は採用しないことが多い。

  • なぜかというと面倒臭いから。
    速く返さないといけないときとかは一つのファイルにたくさん書いたりする。

    • それはそれでいいと思う。
      そのソフトウェアが求められている関心事による気がする。
      人が運用する上での複雑性を解決するのが Clean Architecture だったりするし、
      速く返さないといけないとかだと技術的なアプローチが必要になるので、そのときどきにあったアプローチが必要
      Clean Arhitecture は万能薬ではないので、適材適所なアプローチが必要になってくる。

本の内容に関して

「本当の重複」と「偶然の重複」があって、

  • 重複を排除すれば無条件で良いと思っている人がいるが、そこについて書かれているのが嬉しかった。
    • このコードを重複させるべきかどうかという点を考えた時に、
      テストできるコードが設計ができるコードというわけではないと言われたりもした。

組織の形態がアプリケーションに反映されてしまうという法則がある。

  • 組織の形態はなかなか変わらないが、アーキテクチャはよりよいものにしたいと思うときがあるが、みなさんどうしていますか?
    • うちは microservice を採用していて、新しく入った人にはローテーションして多くを触ってもらうようにしている。
      そういう風に知識を蓄えてもらうようにしている。
  • 組織変えなきゃなと思いながらコードを書いたりもしている。
  • 何かサービスを作ろうとなったときに、新しく部署が生まれてそこで作るような文化になっている。
  • スクラッチで作られるサービスがたくさんあるので、横軸で共通で使えるようなライブラリとかプラットフォームがあったらいいと思うが、
    いまのところ組織と同じ形になってしまっている。
  • アーキテクチャ設計と組織設計って同じだと思っていて、組織設計やる気持ちがないとアーキテクチャ設計できないと思う。
    組織設計はマネージャーがやるというマインドだとできないと思う。
  • 結論、組織設計から逃げない。

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門に行ってきました

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門

https://supporterzcolab.com/event/533/

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

 

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

 

登壇者の方は、留学の経験があるが、

留学したからといって、すぐに英語ができるわけではない

それがきっかけになって勉強しようと思った。

 

その辺の本屋で、「2語で伝わる英会話!」とかいう本が多いが

そういう楽して学べる英語は本当の英語ではない。

 

この勉強会を通して、

みなさんが英語への一歩が踏み出せればよい。

エンジニアが英語できると何がよいか?

嬉しいことはすでに分かっている。

が、英語を勉強するのはとてもしんどい

なので、目標やモチベーションが大切。

嬉しいこと1: 入出力のスペック大幅アップ

入力

  • 最新のドキュメントが読めるようになる。
  • 疲れずに英語のドキュメントが読める。

出力

  • 例えば、技術ブログなどを英語で書くと、海外の人も見てくれる。
  •  OSS 活動がしやすくなる(PR  のコメントやコミットメッセージなど)

嬉しいこと2: 市場価値の高い人材になれる。

嬉しいこと3: もちろん、お給料が増える

いろいろなデータを見ていると、英語ができていると年収が上がる人が多い。

嬉しいこと4: 転職の際の選択肢が広がる

例えば、海外企業に勤めたいというのがまず浮かばない。

それは、英語ができないから。

それで選択肢が減っているのはとてももったいない。

嬉しいこと5:  かっこいい。

 

英語のジャンルを4象限に分けたとき

  • listening (リアルタイム・自分でコントロールできない)
  • speaking (リアルタイム・自分でコントロールできる)
  • writing (ノンリアルタイム・自分でコントロールできない)
  • reading (ノンリアルタイム・自分でコントロールできない)

どれが難しいか?

ノンリアルタイムの方が、翻訳ツールなど使えるので簡単

事前に準備できるspeaking, writingは、自分でコントロールできるので簡単

逆に準備できないのは、相手に依存しているので、むずかしい。

準備すれば誰だって英語でスピーチできる。

結論からいうと、

listening が一番難しい。

speaking ができれば、writing はそれを書くだけなので speaking のほうが難しい。

エンジニア向け、英語表現テンプレート

英語の人は、あいさつの始まりに「調子どう?」みたいなのをめちゃめちゃ言う。

ただ、how are you? はほとんど言わない。

what’s up の返答は i’m fineじゃだめ

最近なんかあった?とかそういうことを聞かれている。なので返答は難しい。

 

ずっとyesを使ってると、硬い人だと思われるので、いろんな表現を使えると良い。(yup など)

コミットメッセージとかは、日本語よりも英語のほうが簡単だったりもする。

主語とかいらないんで、動詞から始まっていい。

speaking 攻略

格好つけずに簡単に喋る

 

発音

日本人を知ってる海外の人は、日本人が英語の発音がひどいことは分かっているので

海外の人もそこは日本人に合わせて喋ってくれる。

逆に、自信なくして小さい声で喋ると、もっと伝わらないのでよくない。

 

喋りながら、発音が難しい単語は避けるようにする。

R と L の発音は本当に難しい。

が、R と L を入れ違えたときに存在しない単語だったら

相手が意味を汲み取ってくれるので、意外と大丈夫だったりもする。

Q & A

Q1.

英語をはじめたきっかけは?

A1.

学生の頃の先生が良かった。

 

Q2.

こういう勉強方で良かったというのはあるか?

A2.

実際に喋るのがよい。skypeとかで喋れるサービスもある。

DMM 英会話など。

 

Q3.

話をしていると、分からない単語があって、スペル自体も分からないから調べようがなさそうだがどうすればよいか?

A3.

スペルが分からなくても、それっぽい単語でぐぐったら、googleがもしかしてこの単語?とサジェストしてくれるので、それをつかっている。

 

Q4.

下手な英語を喋って相手を怒らせたときの対処方は?

A4.

そもそも怒らないと思う。そうとう変なこと言わなければ。

 

Q5.

日頃、ものを主語にしてしまうことがおおいが、人を主語にしたほうがよい?

A5.

いや、それでもよい。

 

Q6.

ゲームのチャットで英語を勉強するのはよいか?

A6.

何もしないよりは良いが、ゲーム特有のスラングとかもあるので、仕事で喋るほうがよい。

 

Q7.

どの程度英語ができたら市場価値として英語ができると言えるか?

A7.

どのくらいかはわからない。ただ、自分は英語できますと言える。

 

Q8.

実務として、エラーを検索するときは、どういう検索の仕方をしたほうがよいか?(効率の良いググり方は?)

A8.

普通に日本語で検索することもある。そのほうがわかりやすいので。

 

Q9.

英単語を覚えるためにどっかに保存している?

A9.

頭の中に保存している。話すときに何か見たりはできないので。

補足:

alcというサイトが良い。

辞書のようなサイトだが、辞書ではなくて、その単語を使った例文が表示される。

 

Q10.

日常で使うテンプレートとかある?

A10.

それが難しい。エンジニアに限定すると用途に特化して作れるが、日常会話は難しい。ので、テンプレートは持っていない。

 

Q11.

英語のpod cast など使っているか?

A11.

聞いていない。ただ、聞くとしたら自分の英語レベルにあったものを聞いたほうがいい。

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

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つ(可用性、コスト効率、耐障害性、スケーラブル)を満たすために

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

可用性とは
→ システムが停止してしまったときに、復旧までの時間が短いこと
例えば、ec21台で動いているのであれば、停止したときのために 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: 違う。これは。ロギングサービス
 awsapiを全てロギングするサービス
なので障害が起こったときに、原因追求になる。

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

 

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

 

原則2つ目

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

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

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

 

例えば、前提として、

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

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

 

耐障害性のない例だと

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

耐障害性のある例だと

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 b5つのサーバーにデプロイし、

予備として 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にそれぞれpublicprivateのサブネットを作成する。

同じ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/HTTPSSQSSMS、メール

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 アドレスの範囲に区切るということ。

SGNACLの比較

この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 EncryptionTDE))

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アカウント
  • アプリケーションアカウント
  • アプリケーションの保護(オンプレミスと同様)
    安全なパスワードストレージとパスワードポリシーを使用する。

OSip 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 IOSP20 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のみ。パブリックIPOSが知らない情報。

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に行ってきました

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アプリを作るときのデザインのガイドライン

「割り勘オンライン」をリリースしました

趣味で作っているAndroidアプリ

「割り勘オンライン」を728日にGoogle Playで公開しました。

https://play.google.com/store/apps/details?id=com.jp.acchan.groupdutch

 

「割り勘オンライン」は

立て替えが何度か発生する関係の人との間で役にたちます。

領収証をとっておく必要がなく、

何をいくら立て替えたのかをスマホで共有することができます。

 

また誰がいくら多く払っているのかを

ボタン1つで計算することができます。

こんなときに使ってほしい

友達と旅行中に立て替えが発生するとき

旅行をしていて、

「今回ガソリン代払っとくよ~」とか

「今回レンタカー代払っとくよ~」と、立て替えをして

旅行が終わってから精算。ということがないでしょうか。

 

そんなときに、「割り勘オンライン」を使えば

誰が何を支払ったのかのメモをアプリで共有することができます。

 

また、立て替えた結果、誰がいくら多く払っているのかを

すぐに計算することができます。

恋人とお財布を分けてて、きっちり精算したいとき

私自身がそうだったのですが、

恋人と例えば

「今日スーパーで買い物してきたよ」とか

「コンビニまとめて払っておくね」とかしているけど

きっちり精算したい人はいませんか?

 

1ヶ月分のレシートを残しておいて

1でレシートを計算して精算、ということは面倒ですが、

「割り勘オンライン」があれば、レシートを取っておく必要も

電卓で計算する必要もありません。

 

まだリリースしたばかりで
至らない点が多いと思いますが、
気になった点や改善点があればレビューに書き込んでいただけると
幸いです。

【食事&景品付き】エンジニアの為の合コン(エジコン)に行ってきました。

【食事&景品付き】エンジニアの為の合コン(エジコン)

https://engineer-quality-life.connpass.com/event/93073/

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

エンジニアトークしていい前提なので話しやすい

日頃僕はエンジニア以外の方と話すときは

エンジニアの話題をしても話が広がらないので

頑張って他の趣味の話をするのですが、

技術の話のほうがいろいろ話せたり興味があります。

 

エンジニアトークしていい前提なので

自己紹介のときから「どんな言語・技術を触ってます」と言えるので

エンジニアな話ができてとてもよかったです。

 

また、これは偶然だったのかもですが、

私のテーブルには

  • Webのサーバーサイド
  • Webのフロントエンド
  • インフラ
  • 組み込み系

の人がいて、いろんな話が聞けて楽しかったです。

運営の方がいろいろしてくれている

現地に着いてから聞いた話だったのですが、

もともと用意していた会場が使えなくなり、急遽新しい会場で開催してくれたとのことでした。

少しバタついてしまっていましたが

急な対応をしてくれた運営の方には感謝です。

 

また、歓談の途中に、みんなで行うエンジニアクイズを企画してくれていました。

httpの意味は?」という問題だったり

「フォン・ノイマンがコンピュータを作ったときに言った言葉は?」

というちょっとトリビア的な問題だったりして

みんなで盛り上がってクイズ大会ができました。

 

またクイズに正解すると景品ももらえました。

偶然私が正解したクイズの景品が、映画のギフトカードだったのですが、

それを口実に女性に「一緒に行きましょう」と誘うことができました。

誘う口実になる景品を考えてくれた運営の方には感謝です。

まとめ

とても楽しかったです。

 

あまり合コンという意識をせずに

単純に集まった人で歓談を楽しむような雰囲気だったので

私も緊張せずに楽しむことができました。

 

ただ、connpassの予定では女性は6名の参加だったのですが、

当日になると欠席が多く、実際に集まってくれたのは2名でした。

 

このあたりは、運営の方が次回にむけて改善していきたいとおっしゃっていました。

 

あと強いて言うなら

僕がいないほうのテーブル(入り口から遠い方)のテーブルで

運営の方が喋りすぎてなかったかなとちょっと心配になりました。

参加者同士の会話よりも、運営の方の話を参加者が聞いているような時間がながく思えたので、

そこだけちょっと心配でした。

 

エンジニアはやっぱりエンジニアトークで盛り上がりやすいので

それができる人で集まる合コンはいいものですね!

ソフトスキル4章まとめ

まず始めに、私達は人との良い接し方をとらないといけないということを認識しよう

私達はコードのために働いているわけではなく、人のために働いている

私達は一日中コードを書いていたいと思うかもしれない

人との調整ごとなどできればしたくないと思うかもしれない

 

だが、そこについては一度考えなおしてみるとよい

私達が書くコードは、コンピュータから「この実装をしてくれ」と言われて書くものだろうか。

 

いや、違う。

人から「こういうことを実現したい」と言われてコードを書くのだ

コードに落としこむ内容を決めるために会議に出るし、ビジネス的な戦略を練ったりするだろう

 

このように、私達がコードを書く理由は人からきているのだ

自分の仕事はコードを書くことだと思い込むのではなく、

他の職種同様、人と接する職種だと認識しなくてはならない

このことから、私達は人との良い接し方をとらなければならない

人との接し方を学ぼう

「大切にされている」と誰もが感じたい。

人と接するときに最も重要にしたいことは、相手がどうされたいかを意識することだ。

 

では、相手はどうされたいか?

要望はいくらでもあるだろうが、最も根本的な要望は「大切にされたい」ということである。

この最も根本的な要望を常におさえたまま、人とは接しなければならない。

 

仮に、人を見くびったり、存在を否定するような接し方をしてしまった場合、

相手は自分に対して反抗的な姿勢になってしまうことを肝に銘じよう。

決して批判してはならない

人は大切にされたいという心理が理解できると、

批判が目的の結果を生み出さないことも理解できるだろう。

 

また、良い行動を褒めるほうが、悪い行動を懲らしめるよりはるかに効果的だということは、

数々の研究成果で示されている。

 

リーダーである人なら、メンバーにベストを出させたいときには、

余計なことは言わずに褒める言葉を繰り返すのがよい。

 

一つ例を出すと、あなたのこれまでの上司で、

失敗に対して叱責を繰り返す人がいたら、そのときのことを思い出してほしい。

叱責されて、やる気が出ただろうか、モチベーションが上がっただろうか。

多くの人は、あなたと同じようにモチベーションはあがらない。

他人の立場になって他人主体で考えよう

相手の立場になって物事を考えたり、話し方を変えるようにしよう。

そうすることで、相手のことを軽んじたりしたり批判したりすることを避けることができる

 

相手の立場になるうえで重要なことが、相手が何を望んでいるか、

何を大切にしているかを把握することだ。

自分が話をする番になっても、相手の立場になって、相手中心の話題になるようにしよう。

 

例えば

ある機能をある特定の条件で実装したいとなった場合、それをそのまま上司につつえるよりも、

その実装をすることで相手(上司)にどんないいことがあるのかを伝えるほうが、

承認をもらえる可能性がグッと高くなる。

議論は避けなければならない

ソフトウェア開発者の我々は、論理的な議論によって最適な解を得られると思っている。

 

しかし、それは間違いだ

議論する人は、思ったほど論理的になれない。

 

見た目は大人であっても、時には感情を剥き出しにするし、何か反論されたときなどには感情的な意見を言ってしまったりする

そういった理由で、議論によって最適な解を導き出せるわけではないので、避けなければならない。

 

泣き叫ぶ子供に正しいことを論じても通じないように、

あなたに冷たくされて人は、あなたの言うことに賛同しないだろう。

 

何かのやり方について賛同できないとき、特にそれに人が関わっているときは

命をかけてまで反対するべきかどうかを考えよう。

自分の意見を諦め、相手の意見を尊重した実績を積み上げれば

いずれ相手は自分の意見に耳を傾けてくれるかもしれない。

 

社交術のために時間を使ったことがなければ、いますぐ始めたほうがいい。

そうすれば自分の人生がもっと楽しくなり、それは値段がつけられないほど価値のあるものだ。

「毒」のある人の扱い方。

他人を蹴落とすことばかり考えていたり、自分を犠牲にして悪いことを集めたりする人はいるものだ。

そういう人に出くわしたら、できる限り早く距離をとったり、逃げ出したりしよう。

それが最善だ。

もし、どうしてもその人と関わらなければならない場合の選択肢は

  • 相手のご機嫌をとる
  • 異動を検討する
  • 感情的にならないように最小限の範囲で接する

ことだ。

【集まれKotlin好き!Kotlin愛好会 vol2】に行ってきました

集まれKotlin好き!Kotlin愛好会 vol2

https://love-kotlin.connpass.com/event/91710/

に行ってきたので、その時のレポート

談義: 「JavaからKotlinにコンバートする際にj2kコンバータをカスタマイズした話」by paraya3636さん

資料

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

Java から Kotlin に変換する際に苦労した点

通常、Android Studio で変換すると思う。このとき、j2k コンバータが使われている。

ただ、この j2k コンバータは問題がある。

それは、強制的にnon null 変換されること

これを調べてみると、

引数や戻りの型に non null のアノテーションがついてないと、

nulableな変換にしてくれない。

そのため、そのまま実行するとクラッシュしてしまう。

解決案1

目視で全部チェックする

解決案2

Kotlin 化して全部テストする

ただ、この2つの案だと、やる際に手作業で辛すぎる。

さらに考えて、

コンバータを改造すればいいのではないかと考えた。

Java から Kotlin に変換するツール「j2kコンバータ」をカスタマイズした話

ステップ

  1. Kotlin を build する環境を整える
  2. typeConverter.ktを編集
  3. チャイルド IDEA を実行
  4. コードをコンパイルする。

Kotlin の build 環境は長くなるので割愛。

資料のURLとかをみてね!

カスタムコンバータの使い心地は?

クラッシュの確率が激減した。

信頼感がupして、レビューを簡素にすることができた。



談義: 「Java で書かれた Android アプリを Kotlin で書き直すまでの話」by Ryutaro Miyashitaさん

資料

以下、談義を聞きながらのレポート

書き直す際に

最初は部分的に使えるところで使っていこうという形だった。

次に、既存の画面を書き換えてみた。

次に、新しい機能追加の際には Kotlin を使い始めた。

チーム内に Kotlin が浸透してきた。

Javaとつなぎこみたいときどうすればいいの?

Javaとの共存はもちろんできるが、このコードは Java から呼ぶとか Kotlin から呼ぶとか意識づけが必要。

Kotlin 側に、Java からアクセスさせるためにアノテーションをつけてあげたりする。

ここは Java からアクセスするんだねっていうのを意識する必要がない。

Java には Unit 型はないので、 Java 側に Unit を返すような実装をしなければいけない。

このように、Java 側に Kotlin の都合が侵食していったりする。

Kotlin の旨味を100%引き出したいとなると

Java と Kotlin がお互いに都合をお互いに考えなければいけなくなる。

いっそのこと、Kotlin に書き換えたほうがいいのでは?となり、

ただ、Kotlin の習熟度レベルはバラバラ。

なので、レビューをしたり、チャットでクイズを出したり、説明したりして、

理解を深めて行った。

結果、5.3万行くらいあった、コードが4.3万行くらいになった。

手作業でやりきったのはいい思い出。

10ヶ月で全部 Kotlin 化した。

その間に機能追加やリファクタリングもできた。

効果

可読性はあがった。

Null Pointer Exception の撲滅。ほぼ出会っていない。

最後に

既存のアプリも段階的に Kotlin 化して行けた。

中途半端に導入するぐらいであれば、全てを書き換えたい。

 → Java と Kotlin 間でそれぞれを意識する手間を省けた

他チームから見た、想定外の効果

 → iOS エンジニアや Scala のエンジニアが Kotlin のコードを読んで交流が生まれるようになった。



談義: 「低レベルな Kotolin 」by tomoya0x00さん

資料

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

Kotolin のbyte型の話。

符号なしで処理をしたいことがある。

kotlin の byte 型に 0x80 を突っ込むと

-128になってしまう。

そこで、

符号なしとして扱ったときの最大値が十分に表現できる型に変換する。

そして、マスクをする。

やり方は、

toInt()して、0xffでandをとる。

チェックサムの話

2の補数表現を考慮して実装をする。



談義: 「webエンジニアが 2ヶ月Kotlin(Android)開発して思ったこと」by achanさん

私の談義です。

資料

以下、概要

日頃はサーバーサイドを触っている

  • サーバーサイド
  • インフラ
  • Kotlin(Android)

ができると、一人でオンラインアプリが作れるようになる。

webもできてアプリもできるって人は少ないように感じる。

webの現場で「それ、アプリでできますよ」って言えるようになりたい。

Kotlin楽しい

これから始める人はぜひ実機デバッグで欲しい。

動いたときの感動がある。

型に厳密な言語は楽しい

IDEが叱ってくれる

型を書くのは頭の整理になる。

webだといろいろ複雑な要素が多いし、環境が違うこともあるが

Kotlinだと、同じ問題に当たっている人が同じ解決策で乗り切れることが多い。

Kotlinの世界を見て思ったこと

  • viewとロジックの分離が難しい
  • クライアントにインストールされている古いバージョンへの対応
  • 端末依存問題

まとめ

サーバーサイドを日頃触っているが、

Kotlinを触って新しい世界に触れるのは良い。



談義: Property Getterby scacheさん

資料



談義: 「完全に理解した気になる Kotlin Coroutines」by takahiromさん

資料

apiが多いが、基本的なところから理解したい。

coroutinesはスレッドの上で動く、動きは確認できる。

中断もできる。



談義: 「KotlinJs でも Coroutines」by Ryo Sakaguchiさん

資料

react wigh kotlinのインストールは簡単

npm で数コマンドたたくだけでできる!