こつつみ

コツコツ積み上げる

目標をスプレッドシートで管理する

 

今日は2021/5/1だ。この記事の通り1/1に目標を決めて4ヶ月がたった。

kotsutsumi.hatenablog.com

 

上の記事では以下のような目標を立てた。

 1. 自分の意見をもつ

- 毎週このブログを更新する
- 毎日取ったメモをまとめる

2. エンジニアリングの追求

- 本業で 1 レベルの上の評価を得る
- 技術書を20冊読む
- 技術記事を10個書く

3. 生活の充実

- ルーティンの確立 (ToDoリストを作らずに全てカレンダーで管理する)
- 自己投資を惜しまない
- 同居人とランニングを続ける
- 毎日筋トレを10分する

今回は自分が目標に向かって取り組んでいるうち、目標スプレッドシートについて振り返る。

目標スプレッドシートとは

目標スプレッドシートとは、以下のような目標を数値化し、それに対する実際の行動を記録している。

項目としては

上の目標に関連させて

  • 学習時間
  • メモ数
  • 読書数
  • ブログ投稿数
  • 自己投資額

を記録している。

f:id:ue_sho:20210501150544p:plain

4ヶ月経っての振り返り

良かった点

  • 実際に自分がどれだけ行動しているか可視化できる
  • 毎日入力するので振り返りができ、習慣化された (最初は一週間ごとに入力していた)
  • どんな一日、一週間、一ヶ月だったかの振り返りがしやすい (別にカレンダーでの1日の記録を行っているため)
  • やらなきゃという気持ちで行動に移せる (マイナスの面もあり)

悪かった点

  • 欠乏ベース(足りないのを埋める)になってしまっているので、途中で嫌になりそう
  • やらなきゃというマイナスの気持ちにもなる
  • スプレッドシートは改善の余地がある (項目や値や自動入力)
  • 達成する楽しい気持ちを作れるような仕組みづくりが必要

最後に

目標スプレッドシートの悪かった点を挙げているが、総評としては始めて良かった。

自分がどれだけ行動しているかというのが可視化できているので、頑張る気持ちが継続できている。

皆さんも試してみてください。

「イシューからはじめよ」を読んだ

本の基本情報

本の基本情報について紹介する。

  • 著者名:安宅和人
  • 書籍名:イシューからはじめよ ─ 知的生産の「シンプルな本質」
  • 出版社:英治出版
  • 発売日:2010/11/24
  • 頁 数:262ページ

内容

イシュードリブン: 「解く」前に「見極める」

イシューとは知的な生産活動の目的地となるものだ。

イシューを知り、それについて考えることでプロジェクトの立ち上がりは圧倒的に速くなり、混乱の発生も予防できる。目的地の見えない活動はつらいが、行き先が見えれば力が湧く

「これは何に答えを出すためのものなのか」というイシューを明確にしてから問題に取り組むなければ、後から必ず混乱が発生し、目的意識がブレて多くの無駄が発生する。

なので、問題を解くまえにイシューを見極めるのだ。

生産性を上げたいなら「バリューのある仕事」をする必要がある。

「バリューの本質」は「イシュー度」と「解の質」の2つの軸から成り立つ。

f:id:ue_sho:20210424172355j:plain

本の著者は良いイシューの3つの条件を上げている。

  • 本質的な選択肢である
  • 深い仮説がある
  • 答えを出せる

そして良いイシューの表現は「〜はなぜか?」と言う「Why」ではなく、「Where」「What」「How」で表す。

ここまで読んでイシューの重要性や考え方を知ることが出来る。 しかし、イシューの見極めは読んだだけでは身につかない。これは経験をしていくしかない

仮設ドリブン1: イシューを分解し、ストーリーラインを組み立てる

イシューの分解

大元のイシューを「答えが出せるサイズ」にまで分解していくことで部分ごとの仮説が明確になり最終的に伝えたいメッセージが明確になる。

多くの検討テーマでは分解するための型が存在する。しかし、何よりも強力なのは「自分の視点を加えた型」を作ることだ。

これも経験をしていくしかない。読んで理解出来るものではない。

ストーリーラインの組み立て

ストーリーラインは 立ち上げ段階、分析・検討段階・まとめ段階 のどこでも使える。

ストーリーラインの型として2つ挙げられている。

  • 「Why」の並び立て
  • 空・雨・傘

現在、報告資料を作る機会があるのだが、ストーリーができていないとダメ出しを何回も受けている。

イシューがありサブイシューに分解と言うのができていない。ここを疎かにしてストーリーは作れないことを頭に入れとかなければならない。

仮設ドリブン2: ストーリーを絵コンテにする

、「最終的に伝えるべきメッセージ(=イシューの仮説が証明されたもの)」を考えたとき、自分ならどういう分析結果があれば納得するか、そして相手を納得させられるかと考えることだ。そこから想定されるものをストーリーラインに沿って前倒しでつくる。

この分析イメージ作りの作業が「絵コンテ」だ。

f:id:ue_sho:20210424183747p:plain

絵コンテ作りの3つのステップがある

  • 軸の整理
  • イメージの具体化
  • 方法の明示

軸の整理

「比較」が言葉に信頼を与え、「比較」が論理を成り立たせ、「比較」がイシューに答えを出す。優れた分析は、タテ軸、ヨコ軸の広がり、すなわち「比較」の軸が明確だ。そして、そのそれぞれの軸がイシューに答えを出すことに直結している。

つまり、分析では適切な「比較の軸」がカギとなる。どのような軸で何と何を比較するとそのイシューに答えが出るのかを考える。

定量分析の考え方3つ

  • 比較
  • 構成
  • 変化

この3つを掛け合わせることで多くの表現が出来る

f:id:ue_sho:20210424184700p:plain

イメージの具体

数字が入ったイメージを作っていく中で、「このあたりの軸の取り方が要になる」「このヨコ軸は細かく値を取らないといけない」と言ったことがわかるようになってくる。

分析の本質は比較だと述べた。したがって分析、また分析的な思考における「意味合い」は、「比べた結果、違いがあるかどうか」に尽きる。つまり「比較による結果の違い」が明確に表現できていることが「意味合い」を表現するポイントになる。明確に理解し得る違いとして、典型的なのは次の3つだ

  • 差がある
  • 変化がある
  • パターンがある

これらのような最終的に欲しい「意味合い」を分析イメージとしてかき入れていく。分析開始前に必要な結果に対する強い意識を持っておくことで、結果がうまく出ないときにも落胆し過ぎずに済み、諦めてはならないラインも明確になる。当然「何を生み出すためにこの分析をやっているのかわからない」ということも回避できる。

分析する前に結果をイメージすることがなかったので、意識していかないと出来ない。先に仮説を持っておく仮説思考と同じだ。

方法の明示

どうやって値をとるのか、実際のアプローチについても考えていく必要がある。

欲しいデータからアプローチを考える。そうすることで、既存の手法では取れないと分かるかもしれない。

アウトプットドリブン: 実際の分析を進める

最初に大切なのは「いきなり分析や検証の活動をはじめない」ことだ。最終的に同じイシューを検証するための分析であっても、それぞれには軽重がある。

もっともバリューのあるサブイシューを見極め、そのための分析を行う。ストーリーラインと絵コンテに沿って並ぶサブイシューのなかには、必ず最終的な結論や話の骨格に大きな影響力をもつ部分がある。そこから手をつけ、粗くてもよいから、本当にそれが検証できるのかについての答えを出してしまうわけだ。

重要な部分をはじめに検証しておかないと、描いていたストーリーが根底から崩れた場合に手がつけられなくなる。ここはストーリーラインのなかで絶対に崩れてはいけない部分、あるいは崩れた瞬間にストーリーの組み替えが必要となる部分であり、具体的には、カギとなる「前提」と「洞察」の部分になるだろう。

「空・雨・傘」で言うと「空」が肝の前提部分となり、ここによってストーリーが根底から変わってくるので、「空」から取り掛かるのが良さそう。

アウトプットする上で気をつけなければいけないのが、「自分たちの仮説が正しいと言えることばかり集めてきて、本当に正しいのかどうかという検証をしない」と言うことだ。

都合の良いことだけを集めるのではないのだ。

正しくアウトプットを理解し、注力し、トラブルを回避すれば、最後は「軽快に答えを出す」だけだ。どんなイシューもサブイシューも、答えを出してはじめてそれに関する仕事が終わった、と言える。

ここで大切なことは「停滞しない」ことだ。要は手早くまとめていくのだが、そのためには次のコツを知っておきたい。停滞を引き起こす要因として、最初に挙げられるのが「丁寧にやり過ぎる」ことだ。「丁寧にやってなぜ悪いのか」と言われるかもしれないが、生産性の視点から見ると、丁寧さも過ぎると害となる。

僕の経験では、「60%の完成度の分析を70%にする」ためにはそれまでの倍の時間がかかる。80%にするためにはさらに倍の時間がかかる。

一方で、60%の完成度の状態で再度はじめから見直し、もう一度検証のサイクルを回すことで、「80%の完成度にする半分の時間」で「80%を超える完成度」に到達する。

単に丁寧にやっていると、スピードだけでなく完成度まで落ちてしまうのだ

つまり、回転数を意識する。自分の仕事であるエンジニアリングでは活かせるところはなさそう。と思っていたが、設計書のレビューとかは何度も見てもらうことでレベルが上がっていくことはある。

何にでも当てはまる。回転数を意識しよう。

追記: エンジニアの技術でも同じだった。

世界的技術イケメンの作り方|牛尾 剛|note

メッセージドリブン: 「伝えるもの」をまとめる

ストーリーラインで組み立てた以下のを基に作っていく。

  • 「Why」の並び立て
  • 空・雨・傘

ストーリーを磨き込む。ストーリーがないと相手は理解できない。

相手に何を思わせたいのか、相手にどう行動をさせたいのかを考えながら作っていく。

最後に

これが出来るようになれば確実に結果を出せるとは思う。しかし、再三言っているが、読んだだけでは身につかないので、実践して身につけていくしかない。

毎日の仕事の中で「この作業って本当に意味があるのか?」と思ったら立ち止まって、「それは本当にイシューなのか?」と問いかけることから始めよう。

実践することを肝に銘じて行動していきたい。

自分にとってはめっちゃくちゃ良い本でした。ぜひ読んでみてください。

「実践版GRIT やり抜く力を手に入れる」を読んだ

本の基本情報

本の基本情報について紹介する。

  • 著者名:キャロライン・アダムス・ミラー
  • 書籍名:実践版GRIT やり抜く力を手に入れる
  • 出版社:すばる舎
  • 発売日:2018/2/21
  • 頁 数:378ページ

どんな本?

アンジェラ・ダックワースが提唱するGRIT

グリットとは、「高い目標に対する情熱的な追求であり、周囲の人の畏敬の念を引き起こし、より良い人間へと成長し、精神的な持続的幸福を獲得し、ポジティブなリスクを冒し、最高の人生を送りたいというモチベーションを引き出すもの」のことであり、

「人生の成功」に必要なものは「才能」ではなくその人が持つ「情熱」と「粘り強さ」からなる「やり抜く力」だ!

と言っている。

情熱や粘り強さがないと感じている人には良い本である。

本の目次

以下は本書の目次です。

  • Introduction 幸せになるための科学と実践
  • Chapter1 「グリット」とは何か?
  • Chapter2 こうして低いグリットの低い世界が作られた
  • Chapter3 グリットを高めるための下準備
  • Chapter4 「本物のグリット」とは何か?
  • Chapter5 良いグリット
  • Chapter6 悪いグリット
  • Chapter7 グリットの正しい育て方
  • Chapter8 情熱
  • Chapter9 幸福感
  • Chapter10 目標設定
  • Chapter11 自制心
  • Chapter12 リスク・テイキング
  • Chapter13 謙虚さ
  • Chapter14 粘り強さ
  • Chapter15 忍耐
  • Chapter16 グリットの未来

本を手に取ったきっかけ

自分の仕事はエンジニアだ。

現在は休みの日とかでも学習を続けられてはいるものの、「いつか飽きて辞めてしまうのかなー」という思いと「このまま続けて優秀なエンジニアになりたい」という思いがごちゃまぜになっている。

今の仕事に高いモチベーションはあるものの、続けられるのか不安があり、この本を読み始めた。

考えたこと

良いグリットや悪いグリットの例、なぜグリットの低い世界が作られたのか。を通してグリットがどういったものか理解した。

結論を言えば、やり抜く力を手に入れるためには高い目標を持つことが大切なんだと解釈した。

報酬を得るのに一生懸命頑張る必要がなく、親がこの世からすべての苦難を取り払ってくれて、卓越性の基準が凡庸なレベルにまで下がり、実社会ではランチの仕出しや通勤手当など様々な特典がついてくるという環境で、どうしたらもっと上を目指そうと思えるだろうか?

現在の世界で目標を見つけることも難しい。とも感じた

目標を見つける

グリットは 高い目標に対する情熱的な追求

この高い目標がないことがモチベーションに起因していることを再認識した。

目標研究では、目標が少なくとも次の4つの機能を果たすことが明らかになっている。

  1. 目標には、私たちの注意力(認知面・行動面の両方)を、フォーカスすべき重要な事柄に向ける働きがある。目標が定まっていないと、目的を整理することができず、いつでもどこでも様々なことに気を取られ、意味のある活動をするチャンスを棒に振るリスクが高くなる。「フィードバックのない目標と、目標のないフィードバックは、どちらも無意味だ」という言葉の通りだ。目標を持たないというのは、人生の最期に─あるいは日々の日常においても─自分の成長具合や、今持っている能力や、努力の程度を知るための評価システムを持たないのと同じだ。
  2. 目標はエネルギー源となり、高い目標ほど大きなエネルギーが引き出される。そしてそのエネルギーは、高い目標を定めて追求するときに、より高い幸福をもたらすことになる。なぜなら、人は簡単に手に入るものよりも、一生懸命努力しなければ手に入らないものに高い価値を見出し、そういうものに愛着を持つからだ。
  3. 目標は粘り強さを引き出し、特に高い目標ほど、努力を長引かせることができる。そのため当然のことながら、高い目標を達成したときのほうが大きな成果となる。それは他人に割り当てられた目標でも、自分で決めた目標でも、誰かと一緒に決めた目標でも同じだ。
  4. 目標はその人特有のスキルやリソースの発見につながると同時に、自分の抱える課題につながる新たな戦略を見出し、知っておくべき知識を見極めることにもつながる。目標を追求するのに何かスキルが必要な場合、私たちはまず、自分が今備えている能力で足りるかどうかを分析する。例えば、難易度の高いハイキングをしたい人はコンパスを使うことができなければならないし、理想の経済プランを立てるためにはエクセルを使った表計算ができなければならない。スキューバ・ダイビングの資格を取るなら泳ぎのスキルを高める必要がある。もし既に別のところでそのスキルを使って目標を達成していれば、それは自信になるし、たとえそのチャレンジがまったく未経験のものだったとしても、目標があることで、何を身につけたらよいのかピンポイントで知ることができる

しかし、以下のことも書いてある。

何か突出した偉業を成し遂げた人々は、ただ何かの賞や名声を手に入れることだけを目指してやっているのではなく、それをやり遂げることを通して、自分という人間がどんな人間であるかを決め、人生に意味を見出そうとしている

よく分からなくなってきたが、自分は「最強になる」を目指してやっていこうと思う。

ストイックに生活しないともったいないという感覚│意識高い系中島diary

GRIT 演習

実践版ということなのか、ワークとして筆者からの問いかけに答えていくといった演習も多かった。

特に印象に残った問いが「あなたは何のために毎朝起きるのだろうか?(あなたの生きがいは?)」だ。

毎朝何のために起きる!?!?? そんなこと考えたことなかったので、かなり悩む。(今も答えは出ていない)

他にも、VIA診断と呼ばれるもので特徴的な強みを特定しよう、といったものもあった。

自分の5つの「特徴的な強み」を特定して活用する人たちは、目標を追求する上でより幸福度が高く、より良い成果を出しているというものだ。 自分は「誠実さ・親切心・自制心・チームワーク・公平さ」の5つだった。

自分で言うのも恥ずかしいが、この5つは自分に当てはまっていると思う。 改めて自分で認識しておくことで、強みを発揮できる場面は増えていくといった内容だ。(認知行動とかに近い?)

これ以外にも色んな演習があった、全部は自分もできていないので時間を作ってやっていきたい。

最後に

  • 週160km走ったマラソン選手は後遺症が残ったので「悪いグリット」。
  • 女子体操チームの選手が靭帯を2本切断した状態で飛び、金メダルを取ったから「良いグリット」。

筆者によるとマッスル北村は悪いグリットなのだろう。

尊敬する人物を聞かれたら、僕はマッスル北村だと答える。│意識高い系中島diary

高い目標を達成すれば、良いグリット?といったように、上記には違和感があったが、全体を通して見るとモチベーションが上がる場面が何回もあり、いい本だった。

ぜひ読んでみてください。

C言語の単体テストをする上で最強のフレームワーク

C言語単体テストをする上で最強のフレームワークはこちら

  • GoogleTest

github.com

  • FFF (Fake Function Framework)

github.com

Google Test

こちらは使っている人も多いだろう。

GoogleTestを使うメリットとしては何よりも、エラーが出た際にOSSなのでWebでの情報が多いことだ。

私の部署では、以前は CPPTEST と呼ばれる有償のソフトを使っていたがWebに情報がなくて辛い思いをした。

GoogleTestなら日本語のドキュメントもあるし、色々な使い方ができる。

opencv.jp

opencv.jp

基本的には以下のように TEST_P を使っていくのが良いだろう。(個人的意見です) 今回テストする関数は足し算をするだけなので、TEST() で十分ですが参考のためTEST_P() を使ったやり方でやっています。

// add.c
int add(int x, int y) {
    return x + y;
}


// test_add.c
typedef struct {
    int ret;
    int x;
    int y;
} AddTest;

AddTest add_test_table[] =
{
    /*  [OUT]ret,  [IN]x,  [IN]y */
    {   5,                2,        3  },
    {   1000,          500,     500  },
    {   -10,             10,        -20  },
};

class ParamAddTest : public testing::Test, public testing::WithParamInterface<AddTest> {
public:
    void SetUp()
    {
        // 初期値みたいの設定する必要があれば
    }
    void TearDown()
    {
        // 終了処理みたいのがあれば
    }
};

TEST_P(ParamAddTest, add)
{
    int x = GetParam().y;
    int y = GetParam().y;
    EXPECT_EQ(GetParam().ret, add(x, y));
}

INSTANTIATE_TEST_CASE_P(ParamTest, ParamAddTest, testing::ValuesIn(add_test_table));

add_test_table の1行ごとに合計テストが3回実行される。

FFF

これは簡単にスタブを作ってくれるフレームワークだ。

使い方はとっても簡単。 #include "fff.h" をするだけだ。

https://github.com/meekrosoft/fff#hello-fake-world

の例を取り上げる。

https://github.com/meekrosoft/fff#hello-fake-world

Hello Fake World!

例えば、組み込み型のユーザーインターフェースをテストしていて、フェイクを作成したい機能があるとします。

// UI.c
void DISPLAY_init();
// test.cpp
#include "fff.h"
DEFINE_FFF_GLOBALS;

// テストスイートでこのための偽の関数を定義する方法は次のとおりです。
FAKE_VOID_FUNC(DISPLAY_init);

// そして、テストは以下のようになります。
TEST_F(GreeterTests, init_initialises_display)
{
    UI_init();
    ASSERT_EQ(DISPLAY_init_fake.call_count, 1);
}

さて、ここで何が起こったのでしょうか?このフレームワークを使うために必要なことは、fff.hをダウンロードして、テストスイートに含めることだけです。

魔法はFAKE_VOID_FUNCにあります。これは、ゼロの引数を持つvoidを返す関数を定義するマクロを展開します。また、フェイクに関するすべての情報を含むstruct "function_name"_fakeも定義されています。例えば、DISPLAY_init_fake.call_countは、偽の関数が呼ばれるたびにインクリメントされます。

フードの下では、次のような構造体が生成されます。

typedef struct DISPLAY_init_Fake {
    unsigned int call_count;
    unsigned int arg_history_len;
    unsigned int arg_histories_dropped;
    void(*custom_fake)();
} DISPLAY_init_Fake;
DISPLAY_init_Fake DISPLAY_init_fake;

戻り値があるものについても似たようにできる。

そして、戻り値には任意の値が設定できるのだ。

GoogleTest + FFF でのテスト

GoogleTest と FFF を組み合わせることで、どんなテストでも対応できるようになる。

HelloWorldとデータを送信する関数を例に単体テストを作成していく。 (ゴミみたいなコードですけど...)

// send_hello_world.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>

int send_hello_world(int fd) {
    if (fd < 0)
        return -1;
  
    //データ送信
    char s_str[] = "HelloWorld!";         //送信データ格納用
    int ret = send(fd, s_str, 12, 0);
    if (ret < 0)
        printf("send ERROR: %s", strerror(errno));
    return ret;
}


// send_hello_world.h
int send_HelloWorld(int fd);


// stub_socket.h
#include "fff.h"

// send関数をスタブ化する
FAKE_VALUE_FUNC(int, send, const void *, size_t, int);


// test_send_hello_world.c
#include "fff.h"
DEFINE_FFF_GLOBALS;

#include "gtest/gtest.h"

extern "C" {
#include "send_hello_world.h"
#include "stub_socket.h"
}

typedef struct {
    int ret;
    int fd;
    ssize_t send_return;
} SendHelloWorldTest;

SendHelloWorldTest send_hellow_world_test_table[] =
{
    /*  [OUT]ret,  [IN]fd,  [IN]send_return */
    // 成功
    {   12,              2,           12  },
    // fdが不正
    {   -1,              -1,          12  },
    // sendに失敗
    {   -1,              5,            -1  },
};

class ParamSendHelloWorldTest : public testing::Test, public testing::WithParamInterface<AddTest> {
public:
    void SetUp()
    {
        RESET_FAKE(send);
    }
};

TEST_P(ParamAddTest, add)
{
    int fd = GetParam().fd;
    send_fake.return_val = GetParam().send_return;
    EXPECT_EQ(GetParam().ret, send_hello_world(fd));
}

INSTANTIATE_TEST_CASE_P(ParamTest, ParamSendHelloWorldTest, testing::ValuesIn(send_hellow_world_test_table));

これでsocketの戻り値をコントロールできるので、テストができるようになった。

テストを書こう

自分の職場は単体テストを書かなきゃと言っているものの誰も書いていない状態です。

どんなに忙しくても単体テストは書くべきです。

これを見てC言語のテストを書く人が増えることを祈っています。

テストの重要性については別の記事でも読んでください。

クラウド未経験1ヶ月でAWS SAA試験合格しました

3/13に受験を決意し、4/11に受かることに成功しました。 (クラウドの勉強を始めたのも3/8なので、ほぼ1ヶ月でしょう)

私は?

社会人3年目の組み込みエンジニアです。

業務はWiFiとかの開発を行っています。

きかっけ

個人で色々言語を書いていくうちに、C言語での開発に嫌気が刺してしまい...

Webやクラウド系の開発をやりたいと思ってしました。

そこで、まず証明できる何かが欲しいと思い、AWSを受けることにしました。

何をした

まずクラウドをやろうと決意したが、なーーーーんにも知らなかったので

AWS CloudTech - aws-cloud-tech に入って (3/8) 基礎的な知識をつけました。

ハンズオン形式だったので、割とすんなり頭に入ってきて良かったです。

そこそこ動画みて当初は資格なくても何となく違う部署にいけると思っていたのですが、

本気で行こうと思うなら、結果で示さないとと思い資格の受験を決めました。

f:id:ue_sho:20210415221838p:plain

この時のslackを見ると、3/13に受験を決意してますね。


ハンズオン動画を見るのを継続しつつ、3/24にたまたまUdemy見たらセールやっていたので、

みんなお馴染み(?) 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) を1300円で購入しました。

世界最大級のオンライン学習プラットフォーム Udemy https://px.a8.net/svt/ejp?a8mat=3H9XD6+EZEQUQ+3L4M+5YZ77

んで、このUdemyめっちゃむずかったんです...

まあ自分は基礎しか身に付けていないので、高難度なんて解ける訳もなく

こんな結果になってしまいました...

""高難度②26%""

これをやった時は絶望しましたね。受かる気がしなかったです笑

ただ、AWSの資格で覚えたことは全部使うわけではないので、暗記と割り切って頭に詰め込みました。

www.youtube.com

AWS CloudTechに入っているからというわけではなく、AWS SAAに受かるために上の動画は良いかもしれないです。

この動画を受験しようと思っていた日(4/11)の2日前にみて (遅い..)この勉強法にシフトしました。

とりあえず時間もないのでAWS CloudTechの模擬問題を200問2週して、受験当日を迎えました。

受験当日

割と詰め込んだし、意外と受かるだろ〜〜と思っていましたが、 問題解き始めると、、、 かなり難しくてUdemyの高難度と同じくらいに感じました。

知らない単語とかも出てきて結構焦ってましたし、「落ちる」が頭をよぎってしまい全然集中もできなかったです。

最後の問題を解き終え、見直しマークをつけたものだけ振り返って あとは祈りながら最後の結果画面を見ました。

結果

""合格""

ほんと良かったーーーー!

次の日、夕方ごろにメールが届いて点数を見ると、、、

731点

f:id:ue_sho:20210415223902j:plain

多分、あと一問ミスってたら落ちてた気がしますね。

最後に

自分は勉強時間の記録をしています。

クラウドの勉強にあてた時間は、ハンズオン動画も含めて62時間でした。

クラウド未経験でも1ヶ月でAWS SAA試験には合格できますが、割とギリギリでした。

一回で確実に受かりたい人は2ヶ月くらいが丁度良いのかもしれないです(?)

以上、ueshoでした。

これからのビジョン

4/5で僕は25歳になった

4/1からは社会人3年目となった。2年前の今日はプログラミングのプの字も知らなかったのに割と意欲的に取り組めたんじゃないかと思う。

業務では、通信分野・組み込み開発をしている

 

プライベートでは、社会人1年目に、ディープラーニング機械学習から勉強した。その後、競技プログラミングにハマりAtCoderでは緑になった。(下から3番目レベル, 上位30%くらい)

 

社会人2年目では、スマホアプリ開発(Android)、Web開発(フロントエンド、バックエンド)、自宅サーバー設置などしてきた。

 

ただ技術は全てが中途半端だ。 しかし、全てを満遍なく知ることができた。

これからのキャリアを考える上でこんなに良いことはない。

大企業に所属していると配属ガチャと呼ばれるものがある。しかし、本当にガチャなのだろうか? 実力があれば、希望の場所にいけるだろう。

自分がこれから何十年もやることをガチャで決めるのは嫌じゃないのか? 少なくとも俺は嫌だ。だから、色々経験して自分のあったものを探したつもりだ。

現在は、冒頭でも言った通り通信分野で組み込み開発をしている。 満遍なく経験した結果、組み込み開発は好きだけどC言語が嫌いということに気づくことが出来た。 C言語しか経験していなかったら比較のしようもなかったと思う。

社会人3年目、自分は次のキャリアに進むためWeb(サーバーサイド)・クラウドを主軸に置いてやっていく。 そのためにも、実力を示すしかない。

面接でただやりたいと言っても、熱意だけでは仕事はつとまらない。 やりたいことをやるために、先に結果を出す必要があるのだ。

仕事とは別の時間でコツコツとやった結果で、自分のやりたいことができるのだ。 とりあえず、昨日その一環としてAWSのSAA試験に合格することが出来た。 その話は、また別の機会に...

資格は実力じゃないとは言われるが、大企業の社内転職では有用だと思う。 これと今までの経験を合わせることで、クラウドを使った部署にいくぞ。

ガチャなんかに人生を決められてたまるもんか 俺はやりたいことをやるんだ

AWS SAA 用語集をまとめてみた

AWS SAA試験を受けるに当たり模擬試験を受けて、分からない単語が多すぎたので自分なりにまとめる。 かなりボリューミーになってしまった。知りたいところだけ目次から飛ぶのがオススメかもしれない まだ試験は受けていないので、範囲として足りない部分があるかもしれないが、そこはご容赦願います。

概要

  • IaaS (Infrastructure as a Service)
    • OSより上 
    • ex) EC2
  • PaaS (Platform as a Service)
    • Data, Applicationのみ (セキュリティを考えなくて良い?)
    • ex) RDS, lamda, fagate
  • SaaS (Software as a Service)
    • 全部やってくれる
    • ex) S3, cloud watch

AWS Well-Architected フレームワーク

ベストプラクティス

運用の優位性

システムを改善し続けましょう システムトラブルを減らそう ログを記録してモニタリングできているか?

セキュリティ

権限管理などしっかりしましょう 追跡調査。 全てのレイヤーでセキュリティを設定しましょう 継続改善できているか 障害リハーサルや自動復旧の仕組みづくりはあるか?

信頼性

単一障害点がないか?  一個障害が起こったらサービスが利用できないなんてことにはならないように設計するべき 自動的にリソース拡張しているか? 障害の影響を軽減できる仕組みか? これらのテストをしているか?

パフォーマンス効率

最新テクノロジーのメリット理解し、選定できているか? 価値の高い仕事に集中できていルカ? 最新テクノロジーの比較、実験を頻繁にできているか?

コスト最適化

コストを計測し、削減できる取り組みができているか? 差別化に繋がらない高負荷の作業に費用をかけていないか? 費用を分析及び属性化できているか? 部門ごとのタグをつけてみたりなどする。


Compute

EC2

インスタンスファミリー

  • 汎用
    • T3, M5, A1
  • コンピューティング最適化
    • C5
  • ストレージ最適化
    • I3, H1, D2
  • メモリ最適化
    • X1, R5, Z1d
  • 高速コンピューティング
    • F1, P3, G3

インスタンスタイプ

  • ベアメタルインスタンス
    • ハードウェアへのダイレクトアクセスを提供
    • ベアメタルインスタンスを利用することで通常のクラウドサーバーでは不可能な、ホストコンピューターのOSなどにアクセスが可能
    • ベアメタルはユーザーは以下のことができる
      • 詳細なパフォーマンス分析ツールを利用するアプリケーション
      • ベアメタルのインフラストラクチャへの直接アクセスを必要とする特殊なワークロード
      • 仮想環境ではサポートされないレガシーのワークロード
      • ライセンス制限のあるティア1のビジネスクリティカルなアプリケーション

購入オプション

物理ホストの専有オプション

  • ハードウェア専有インスタンス
    • ...
  • Dedicated Host
    • 物理的にサーバーを占有するインスタンスタイプ
    • Dedicated Hosts では、ライセンス条項の範囲で、ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できます。
    • 同じAWSアカウントに属していたとしても、別のIAMグループとは物理サーバーを共有しません。

ECS

  • Elastic Containar Service
  • ECSは、Docker コンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービス
    • これにより、コンテナ化されたアプリケーションを AWS に簡単に実行およびスケールできます。
  • コンテナ実行環境
    • EC2起動タイプ
    • Fargate起動タイプ

EKS

  • Elastic Kubernetes Service
  • コンテナ化されたアプリケーションのデプロイ、管理、スケールを Kubernetes を使って AWS で簡単に実行できます。
  • AWSKubernetes を簡単に実行できるようにするマネージド型サービスです。
    • Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するための管理ツールとして汎用的に利用されるOSSです

Fargate

  • サーバー管理なしのコンテナ実行コンピューティングエンジン
  • AWS Fargate は、サーバーやクラスターの管理の必要なしにコンテナを実行するための、Amazon ECS および EKS に対応したコンピューティングエンジンです。これ自体はDockerの仕組みをサポートするサービス
  • Fargate はコンテナを実行するために仮想マシンクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
  • 以前は、Amazon EKSとFargateの組合せは利用できませんでした
  • 2019年12月より、AWS Fargate の上でKubernetesを利用できるようになりました。
  • Amazon EKS と Fargateはインスタンスのプロビジョニング設定などを自動で構成してくれるため、AWS 上での Kubernetes ベースのアプリケーション開発やその管理を一定程度自動化してくれます。
  • したがって、ECSとFargateの組合せよりも Kubernetesを利用することで、より自動化を達成することが可能です。
ECR
  • ECRは、完全マネージド型の Docker コンテナレジストリです。このレジストリを使うと、開発者は Docker コンテナイメージを簡単に保存、管理、デプロイできます。

Elastic Beanstalk

  • AWS Elastic Beanstalk はECSなどのDocker サービスと連携して、容量のプロビジョニング、負荷の分散、スケーリング、およびアプリケーションの状態の監視の詳細を自動化することができます。
  • AWS Elastic BeanstalkはELBと Auto Scalingを利用してスケーラブルのデプロイを自動化することが可能です。
  • また、AWS Elastic Beanstalkはアプリケーションのバージョン管理を自動化することもできます。
  • AWS Elastic BeanstalkはAmazon ECSなどのDockerにホストされたWEBアプリケーションの展開もサポートしています。
  • Elastic Beanstalk で Docker を使用することにより、容量のプロビジョニング、負荷の分散、スケーリング、およびアプリケーションの状態の監視の詳細を自動的に処理するインフラストラクチャが提供されます。
  • したがって、Elastic Beanstalk を利用することでECRとEKSとの連携してDocker経由のアプリケーション展開を設定しつつ、バージョン管理や状態の監視の詳細を自動化することが可能となります。
  • AWS Elastic Beanstalk は自動的にデプロイタスク (バッチ配布の自動化、容量のプロビジョニング、負荷分散、Auto Scaling、アプリケーションのヘルスモニタリングなど) を処理します。
  • AWS Elastic BeanstalkによりアプリケーションがホストされるAWS リソースをユーザー側で完全に制御することができます。
  • また、Elastic BEeanstalkコンソールを運用ダッシュボードとして、環境の状態とアプリケーションの状態を一目で分かるように表示することができます

Lamda

ステートレスアプリケーションはシステム上のやり取りの状態情報が不要なため、セッション情報が格納されていないアプリケーションのことです。そのため、同じ入力が与えられたときに、どのエンドユーザに対しても同じ応答を提供するアプリケーションとなります。Lambdaファンクションはステートレスなアプリケーション処理をコスト最適に達成できます。

  • Lambda関数が無期限に実行されないようにタイムアウト設定がなされています。
  • 指定されたタイムアウトに達するとLambda関数は実行を終了します。

Lambda Layer

  • 複数のLambda関数でライブラリを共有できる仕組みであり、一定の機能をLayerとしてまとめて利用することができます。
  • これまでは同じライブラリを利用する関数が複数あった場合、全ての関数に対してライブラリを含めてパッケージングすることが必要でした
  • それを、ライブラリをLayerとしてアップロードしておくことで、個々の関数は共通のLayerを使用することができます。

Lambdaエッジ

  • Lambdaエッジ を使用すると、サーバー管理を行わなくても、ウェブアプリケーションをグローバルに分散させ、パフォーマンスを向上させることができます。

Storage

EBS

  • Amazon Elastic Compute Cloud (EC2) インスタンスにアタッチして使用するブロックレベルのストレージサービス
  • 99.999%の可用性を備えるように設計されている
  • 単一のEC2インスタンスのEBSボリュームは、インスタンス用のシステムドライブやデータベースアプリケーション用のストレージなどの頻繁に更新が必要なデータのプライマリストレージとして使用できます。また、継続的なディスクスキャンを実行するスループット重視のアプリケーションにも使用できます。 これらのEBSボリュームはEC2インスタンスの稼働期間とは無関係に維持されます。
  • EBSは用途に応じてボリュームサイズやボリュームタイプを変更することができることが利点の一つです。
  • 同一AZでののみ利用可能
  • EC2 は接続されていた各 EBS ボリュームの DeleteOnTermination 属性 を使用して、ボリュームを存続させるべきか、削除すべきかを判断します
    • デフォルトでは、インスタンスのルートボリュームの DeleteOnTermination 属性が有効化されており、EC2インスタンスの削除とともにEBSも削除されてしますが、
    • その他のボリュームタイプではDeleteOnTermination 属性は非有効化されています。
    • インスタンスが停止してもルートボリュームを維持したい場合は、ルートボリュームの DeleteOnTermination 属性を非有効化することが必要です。それによって、インスタンス削除後にデータを存続させることが可能です。
  • 容量と IOPS の最大割合 は 50:1。例えば、100 GiB のボリュームは最大 5,000 IOPS

ブロックストレージの種類

  • EBSのプロビジョンドIOPSボリューム
    • レイテンシーの影響が大きいトランザクションワークロード向けに設計された極めてパフォーマンスの高い SSD ボリュームです
    • コストがもっとも高いですが、スループットとIO性能が最も高いボリュームです。コスト最適よりも性能が優先される場合には、このボリュームタイプを選択します。
    • 最大 64,000 IOPS までの一貫したベースラインパフォーマンスを提供し、ボリュームあたり最大 1,000 MB/秒のスルー​​プットを実現するように設計されています。
  • スループット最適化HDD
    • 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD ボリュームです
    • これは高いスループット性能を期待しつつ、プロビジョンドIOPS SSDよりも低コストを実現することができます
    • しかしながら、スループット最適化HDDは1000MiB /sのデータスループット性能を有していません。性能は落ちるもののコスト最適を求める場合に選択します。
  • 汎用SSD
    • 幅広いトランザクションワークロードに対応できる価格とパフォーマンスのバランスが取れた汎用 SSD ボリュームです
  • コールドHDD
    • アクセス頻度の低いワークロード向けに設計された極めて低コストの HDD ボリュームです。

S3

  • S3
    • ユーザがデータを安全に、容量制限なく、データ保存が可能な、クラウド時代のオブジェクトストレージです。
  • S3 Glacier
    • 安全性とコスト効率を重視したアーカイブ向けストレージ

サーバーサイド暗号化

  • 暗号化種別
    • SSE-S3 : AWSが管理する鍵を利用して暗号化
    • SSE-KMS:Key Management Service(KMS)の鍵を利用して暗号化
    • SSE-C:ユーザが提供した鍵を利用して暗号化(AWSで鍵は管理しない)
  • デフォルト暗号化
    • バケットポリシーを定義することなく、バケットに格納するオブジェクトの暗号化を強制する
    • Amazon S3 はオブジェクトをデータセンター内のディスクに保存する前に暗号化し、オブジェクトをダウンロードするときにS3側で自動で復号します。
    • ログも自動で暗号化されるため、S3バケットの暗号化と別に設定する必要はありません。

クライアントサイド暗号化

  • Client Side Encryption(CSE
    • ユーザーが独自の暗号化キーを利用して暗号化したオブジェクトをS3に保存して、暗号化キーの生成・監理はクライアントで実行する形式です。ユーザーが暗号化キーの管理を実施することが前提となっている

レプリケーション

ストレージクラス

Standard
  • 頻繁にアクセスするデータ,msアクセス
Intelligent-Tlering
  • 変化するアクセスパターンのデータ,msアクセス
Standard-IA
  • 低頻度アクセス用ですが、読み込みはすぐにできるため、突然の利用にも対応できます。,msアクセス
One-Zone-IA
  • データ冗長性は劣るため、アクセスが頻繁ではないデータを低価格に保存するのに向いています。
    • バックアップのコピー
    • 再作成可能なデータサマリーなど
  • レジリエンスが低い単一アベイラビリティーゾーンに保存することによってコストを節約します
  • また、データ取り出しは通常の標準クラスと同じように即時に実行可能です。,msアクセス
Glacier
  • コストが安くデータの長期保存に向いていますが、データ取得に数時間要するストレージです。
  • 最低保持期間が90日と設定されている
  • 迅速読取
    • 1分~5分ほどでデータを取得することができます。即時ではない
  • 大容量取り出し
    • 5〜12 時間必要
  • ボールトロック
Glacier Deep Archive
  • ストレージクラスの方がGlacierよりもコストが安いです。

S3 イベント通知

  • Amazon S3は、以下のサービスを利用してイベントを発行できます
    • Amazon SNSトピック
      • 購読しているエンドポイントまたはクライアントへのメッセージの配信を実行・管理するサービスです。S3をトリガーとしてメールなどを通知できます。
    • Amazon SQSキュー
      • メッセージをコンピュータ間で通信するために利用する信頼性が高くスケーラブルなキューイングサービスです。S3をトリガーとしてStandardキューを配信できます。
    • AWS Lambda
      • コードをアップロードし、サービスがAWSインフラストラクチャを使用してコードを実行できるサーバレスコンピューティングサービスです。 Lambda関数を作成するときに、カスタムコードをパッケージ化してAWS Lambdaにアップロードします。S3をトリガーとしてLambda関数を実行できます。

S3 Select

  • Amazon S3 SelectはシンプルなSQLステートメントを使用してAmazon S3オブジェクトのコンテンツをフィルタリングし、必要なデータのサブセットのみを取得できます。
  • 結果として、Amazon S3が転送するデータ量を削減でき、データ取得に要するコストを削減し、待ち時間を改善できます。

S3 Access Analyzer

  • AWS アカウントの外部からアクセスできるリソースを特定する総合的な解析結果を生成します。S3バケットに対する外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認することができます。

Amazon S3 分析のストレージクラス分析

  • Amazon S3 分析のストレージクラス分析により、ストレージアクセスパターンを分析し、適切なデータを適切なストレージクラスに移行すべきタイミングを判断できます。
  • ストレージクラス分析がフィルタリングされたデータセットのアクセスパターンを一定期間監視することで、ライフサイクルポリシーを設定することができます。

マルチパートアップロード API

大容量オブジェクトをいくつかに分けてアップロードできるようになります。この機能により、新しい大容量オブジェクトをアップロードすることが容易になり、今回のアップロード処理の負荷を軽減することが可能です。

S3に保存されているデータを直接解析することができる機能/サービス

  • Amazon S3では、データを別の分析システムに移動することなく、直接にS3データに対して高度なビッグデータ分析を実行できます。
  • Amazon S3 Select
    • Amazon S3バケット内のオブジェクト内のデータをより迅速かつ安価に分析および処理できるように設計されています。
    • 単純なSQL式を使用してAmazon S3のオブジェクトからデータのサブセットを取得する機能を提供することで機能します。
  • Amazon Athena
    • 標準のSQL式を使用してAmazon S3のデータを簡単に分析できるインタラクティブなクエリサービスです。
    • Amazon S3のデータをポイントし、スキーマを定義し、標準のSQL式を使用してクエリを開始するだけです。
    • ほとんどの結果は数秒以内に配信されます。
  • Amazon Redshift
    • Redshift Spectrumも含まれており、Amazon S3のエクサバイトの非構造化データに対してSQLクエリを直接実行できます。
    • 取得されるデータに基づいてクエリの計算能力を自動的にスケーリングするため、データセットのサイズに関係なく、Amazon S3に対するクエリは高速に実行されます。

S3 Transfer Acceleration

  • S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。
  • これにより、各リージョンからS3へのデータ転送が容易に実行できるようになります。Transfer Acceleration では、Amazon CloudFront の世界中に分散したエッジロケーションを利用しています。
  • エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。

EFS

  • NFS アクセスを提供する分散ストレージ
  • ファイルシステム NFS v4.0/4.1
  • EFS へのアクセスはファイル単位
  • 高負荷のワークロードにおいて、Amazon EFS は 10 GB/秒 を超えるパフォーマンス、および 500,000 超の IOPS をサポートできます。

Amazon FSx

Storage Gateway

  • 標準的なストレージプロトコルを利用してAWSのストレージサービスへのアクセスを可能にするハイブリッドストレージソリューション
  • 標準的なプロトコルでオンプレとシームレスで接続できる
    • ファイルゲートウェイ
      • NFS (v3 and v4.1) インターフェース
    • ボリュームゲートウェイ
      • iSCSI ブロックインターフェース
        • ストレージゲートウェイ キャッシュ型ボリューム
          • S3をプライマリーストレージとして、オンプレミスストレージとのハイブリッド構成を実現する際に利用します。
          • キャッシュ型ボリュームを使用することで、頻繁にアクセスされるデータはローカルのストレージゲートウェイに保持しながら、Amazon S3 をプライマリデータストレージとして使用できます。
        • ストレージゲートウェイのストアドボリューム(保管型ボリューム)
          • オンプレミス環境のストレージをプライマリーストレージとして利用する構成です。
    • テープゲートウェイ
      • iSCSI仮想テープライブラリ (VTL) インターフェース
  • バックアップと親和性

Databases

Dynamo DB

  • 完全マネージド型の NoSQL データベースサービス
  • DynamoDBが保存できるデータ型は次のように分類できます。
    • スカラー
      • スカラー型は 1 つの値を表すことができます。スカラー型は、数値、文字列、バイナリ、ブール、および null です。
    • ドキュメント型
      • ドキュメント型は JSON ドキュメントなどの入れ子の属性を持つ複雑な構造を表すことができます。
    • セット型
      • セット型は複数のスカラー値を表すことができます。セット型は、文字セット、数値セット、およびバイナリセットです。
  • Auto Scaling
    • DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量増加を自動化できます。
    • Global Secondary Index (GSI)
      • Partition Keyをまたいで検索を行うためのインデックス
    • DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。
    • これにより一時的な負荷増加に対して、DynamoDBテーブル処理パフォーマンスの管理が容易になり、アプリケーションの可用性を最大化しつつ、DynamoDBのコストを削減することができます。
  • DynamoDBはそのままではリードレプリカを増やすことができません。後述するDAX を有効化することで、DAXクラスターは、1 つのみのプライマリノードと、0~9 個のリードレプリカノードを構成することができます。

DynamoDB Accelerator(DAX)

  • DynamoDBテーブルはミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現します。
  • DAXはキャッシュを利用しているため特定のデータへの処理が高い場合などに中長期的な性能向上のために対策としては正しいです。
  • しかしながら、キャッシュDBは高コストである

DynamoDBストリーム

  • DynamoDBに行われた追加、更新、削除の変更履歴を保持しとりだし可能
  • DynamoDBテーブルの変更イベントをトリガーにして、Lambda関数などを起動する際に利用します。
  • DynamoDBストリームがデータ処理を動的に実行するといった処理を実現することはできません

ElastiCache

  • 完全マネージド型で、セットアップ、運用、拡張が容易なキャッシュサービス
  • ElastiCacheはインメモリDB型のキーバリューストアの高性能データベースです
  • ElastiCacheはキャッシュデータにミリ秒以下のレイテンシーにアクセスを提供することで、高速のデータ処理を可能にします。
  • したがって、ユーザー行動データの高速な処理には最適なDBであり、行動データ記録に応じたリアルタイムのランキング処理やアイテム出現などを実現することが可能です。

RDS

  • フルマネージドなリレーショナルデータベース
  • RDSの拡張モニタリングを有効化
    • DBインスタンス上のさまざまなプロセスまたはスレッドがCPUをどのように使用しているかを常時モニタリングするためには、RDSの拡張モニタリングを有効化することが必要です。
    • これにより、DBインスタンスのOSのリアルタイムメトリックスが確認できるようになります。
    • RDSコンソールを使用してDBインスタンスのメトリクスを表示でき、CloudWatch Logsからの拡張モニタリングを利用することができます。
    • デフォルトでは、拡張モニタリングメトリクスは30日間CloudWatch Logsに保存されます。
  • レプリカDBで読み取り処理をスケールアウト
    • RRは5台(Auroraは15台)まで増設できる

Aurora

  • スループット
    • MySQLの5倍
    • PostgressSQLの3倍
  • Auroraはリードレプリカを最大15個設置することで、読込処理性能を向上させることが出来ます。
  • 最1つのAuroraのDBクラスターに対して最大 15 個の Aurora レプリカを、1 つの AWS リージョンの各アベイラビリティーゾーンに設置して、読込処理を分散できます。
  • DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。これにより、すべての Aurora レプリカは、最短のレプリカラグで読み込み処理を返すことができます。

Migration & Transfer

AWS DMS

  • AWS Database Migration Service
  • DBのデータ連携を支援するサービス
  • オンプレミスにあるデータベースを短期間で安全に AWS に移行できます

AWS SMS

AWS Snow Family

  • Snowball
  • Snowball Edge
  • Snowmobile // Tokyoにはない

Snowball

  • 「ハードウェアアプライアンス」を利用してオンプレミス−クラウド間の大量データ移行を高速化
  • Snowballアプライアンス
    • セキュリティを考慮して設計されたデバイス (AWSから借りてくる
  • ペタバイトスケールのデータ移行
  • 高いネットワークコスト、長時間かかる転送、セキュリティ面の懸念といった、大規模なデータ転送に関する一般的な課題を解決できます
  • データを簡単、迅速、安全に転送でき、高速インターネットによるデータ転送と比較して、コストは5 分の 1 ほどで済みます。

Snowball Edge

  • オンボードコンピュート能力とストレージを搭載するペタバイトスケールのハイブリッドデバイス
  • Snowball Edge = Snowball + コンピュート +α

  • Snowball Edge Compute Optimized

    • 機械学習、フルモーション動画分析、分析、ローカルコンピューティングスタックなどのユースケースに強力なコンピューティングリソースを提供します。
    • このデバイスは、S3 互換オブジェクトストレージまたは EBS 互換ブロックボリューム用に 42 TB の使用可能な HDD 容量を提供します。
  • Snowball Edge Storage Optimized
    • 大規模なデータ移行と定期的な転送ワークフロー、およびさらに高容量を必要とするローカルコンピューティングに適しています。
    • ブロックボリュームと Amazon S3 互換オブジェクトストレージに 100TB の HDD 容量を提供します。
    • しかしながら、利用可能なボリュームは80TBほどです。

Networking & Content Delivery

ELB

  • Amazon ECS はELBのいずれかのタイプのロードバランサ―を使用できます
    • ALB (Application Load Balancer )
      • HTTP, HTTPS,
      • L7のコンテントベース
      • ALBはURL パスに基づいてリクエストを転送するルールを持つリスナーを作成できます。この方式をパスルーティングと呼ばれます。複数のタスクを実施するEC2インスタンスグループを有している場合は、パスルーティングを使用して1つのALBで複数のバックエンドサービスにトラフィックをルーティングすることができます。
    • CLB ( Classic Load Balancer )
    • NLB (Network Load Balancer)
      • HTTP, HTTPS, TCP
      • NLBはOSIモデルの第 4 層で機能する毎秒数百万のリクエストを処理できる高性能なロードバランサーです。パスルーティングは実行可能ですが、かなりの大規模システム向けの高性能なELB
      • EC2-Classicネットワーク用ロードバランサ-

コネクション

高可用性と負荷分散

  • クロスゾーン負荷分散

VPC

  • Virtual Private Cloud
  • 1アカウントに1リージョンに5つまでのVPC
    • チームが明確に分かれているならアカウントを分けた方が良い (大企業)
  • PCのDNS hostnamesオプションが有効化されていないと、サブネットで起動されたインスタンスDNS名を取得できません。
  • VPC 内で起動したインスタンスがパブリック IP アドレスに対応するパブリック DNS ホスト名を受け取るかどうか、および Amazon DNS サーバーを通じた DNS 解決が VPCに適用されるかは、VPCの操作で決定されます。
  • VPCDNS hostnamesオプションを有効化するためには、 enableDnsSupport 属性を「true」 に設定した上で、enableDnsHostnames属性を「true」に設定して、VPC 内のインスタンスDNS ホスト名を取得可能とします。

VPC エンドポイント

  • インターネットを介さずに、VPC内のサービスからVPC外のAWSサービスに接続することができます。これにより、インターネットを通さずにEWS サービスや VPC エンドポイントサービスにVPC をプライベートに接続する機能です。
  • その際にインターネットゲートウェイ、NAT 、VPNAWS Direct Connect を介した接続やパブリック IP アドレスは必要ありません。
  • VPC と他のサービス間のトラフィックは、Amazon ネットワーク内で完結するためインターネットを経由することはありません。VPC エンドポイントには 2 種類あります。
    • ゲートウェイ
      • ルートテーブルの指定されたターゲットとなるゲートウェイです。サポートされる AWS のサービスを宛先とするトラフィックVPC内外で接続する際に使用します。以下の AWS のサービスがサポートされています。
    • プライベートリンク型(インターフェイスエンドポイント)
      • 対象サービスを宛先とするトラフィックのエントリポイントとなるプライベート IP アドレスを持つ Elastic Network Interface です。以下のサービスがサポートされています。

VPC Peering

VPC PeeringはVPC間を連携させる際に利用します

CloudFront

  • レイテンシーの高速転送により視聴者に安全にコンテンツを配信する高速コンテンツ

データ保護機能

  • CloudFrontの署名付きURLと署名付きCookieは同じ基本機能を提供しており、CloudFrontが配信するコンテンツにアクセスできるユーザーを制御できます。次の点で違いがあります。
    • 次のような場合は署名付きURLを使用してください。
      • アプリケーションのインストールダウンロードなど、個々のファイルへのアクセスを制限したい。
      • ユーザーがクッキーをサポートしていないクライアントを使用している。
    • 次のような場合は署名付きcookieを使用してください。
      • HLS形式の動画のすべてのファイル、またはWebサイトの購読者領域のすべてのファイルなど、制限のある複数のファイルへのアクセスを提供したい。
      • 現在のオブジェクトURLを変更したくない。
  • オリジンサーバの保護
    • オリジンがS3の場合
      • オリジンアクセスアイデンティティ (OAI) という特別な CloudFront ユーザーを作成してS3バケットへの直接的なアクセスを制限します。
      • これにより、ユーザーは S3 バケットへの直接 URL を使用してファイルにアクセスすることはできなくなり、CloudFront を通じて提供するファイルへの安全なアクセスを維持することが可能となります。

Cloud Watch

  • EC2インスタンスのデフォルトメトリクス以外の詳細なログ情報を取得するためには、CloudWatchの2つのサービスを利用する必要があります。
    • CloudWatchエージェント
      • このエージェントを対象のEC2インスタンスにインストールすることで、CloudWatchによりサーバー内部の詳細なログが取得できるようになります
    • CloudWatch Logs
      • CloudWatch Logsは取得したログを集約することができ、EC2インスタンスのログ管理を実施することができます。

Route 53

  • ルーティングポリシー
    • シンプル
    • 加重
    • 複数回答
      • 複数値回答ルーティングにより、Amazon Route 53 が DNS クエリに対する応答として複数の値 (ウェブサーバーの IP アドレスなど) を返すように設定できます。
      • 複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースに値のみを返すことができます。
      • したがって、EC2インスタンス単位での正常・非正常を判断してルーティングすることができます。これはロードバランサーに置き換わるものではありませんが、Route53が設定したインスタンストラフィックが正常であることをヘルスチェックした上で複数の IP アドレスを返すことができ、DNS を使用してアベイラビリティーとロードバランシングを向上させることができます。
    • レイテンシー
    • 位置情報
    • 物理的近接性
    • フェイルオーバー
      • Route 53 のヘルスチェックを使用してフェールオーバー (アクティブ/アクティブとアクティブ/パッシブ) を設定できます。
      • Route53は同じ機能を実行するEC2インスタンスなどのリソースが複数ある場合に、リソースの正常性をチェックして、正常なリソースのみを使って DNS クエリに応答するように Amazon Route 53 を設定することができます。
        • 具体的には、「example.comサイト」が、世界各地の 3 拠点のデータセンターにそれぞれ 2 台ずつ、合計 6 台のサーバーでホストされているとします。
        • それらのサーバーの正常性をチェックし、その時点で正常なサーバーのみを使って example.comDNS クエリに応答するように Route 53 を設定することができます。
      • Route53のフェールオーバー設定のアクティブ/アクティブ構成によって、レイテンシールーティングなどのルーティングポリシーを利用してフェールオーバーを構成することができます。
        • アクティブ/アクティブ構成となり、設定された全リソースを平等に利用することができます。
        • リソースが利用できなくなると、そのリソースを Route 53 が異常として検出し、以後、クエリへの応答に含めることを控えます。
      • フェールオーバー設定におけるアクティブ/パッシブ構成は、プライマリリソースを常に利用可能にしますが、すべてのプライマリリソースが使用できなくなった場合に備えて、セカンダリリソースまたはリソースグループをスタンバイ状態にします。
  • 本環境DR環境(ディザスタリカバリ)と遠隔DR環境を別リージョンに設置して、その管理をRoute53で実施することで、他の選択肢よりもAWSのマネージドサービスを利用した自動フェイルオーバーが利用可能であり、DR対応を自動化することができます。
    • Route53を利用したDR環境の方式としては主に以下の2つが考えられます。
      • コールドスタンバイ
        • Amazon S3をバックアップデータの格納先として利用します。
        • 事前にシステムイメージをクラウド上に準備します。
        • 災害発生時にクラウド上のシステムを起動し、Route53で切り替えることで復旧します。
        • 投資コストを抑えられ、手軽に始めることができる
      • ウォームスタンバイ
        • クラウドのスタンバイ環境にデータを常時レプリケーションします。
        • 通常は、スタンバイ環境を最少構成で稼働させ、災害発生時は必要なキャパシティに変更します。
        • スタンバイ環境の運用が常時必要になりますが、Route53でシステム切り替えを素早く実行することができます
  • レコード
    • CNAMEレコード
    • Aレコード
    • NSレコード
      • あるゾーンに対する権威サーバーを指定するためのレコードです

Direct Connect

  • お客様がキャリヤから調達する専用線の片端とAWS Cloudを、Direct Connectロケーションで接続するサービスです
  • 物理的にAWS側と専用線接続の設定が必要です
    • AWSへの申請と設定などが必要不可欠
  • お客様の大切なワークロードを担うネットワークとして、シングルポイントを作らない事が重要。

Developer Tools

CodePipeline

  • 素早く信頼性の高いアプリケーション更新のための継続的デリバリーサービスを提供
  • ビルドやテスト結果をslackに通知したりできる

X-Ray

  • アプリケーションやその基盤となるサービスの実行状況を把握しパフォーマンスの問題やエラーの根本原因を特定する
  • ユーザーがAmazon API からのAPIリクエストを通じてサービスを呼び出した場合に、AWS X-Rayを使用してユーザーリクエストを追跡および分析できます。
  • API Gatewayは、すべてのAPI Gatewayエンドポイントタイプ(地域、エッジ最適化、プライベート)のAWS X-Rayトレースをサポートしています。
  • そのため、 X-Rayが利用可能なすべてのリージョンにおいて、Amazon API GatewayAWS X-Rayを使用してトレースデータを収集することが可能です。

Management & Governance

Auto Scaling

  • Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行します。このへルスチェックにはEC2タイプとELBタイプの2つのタイプがあります。
    • EC2タイプ
      • EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に、このインスタンスを異常と判断します。
    • ELBタイプ

CloudFormation

  • クラウドプロビジョニングを高速化
  • 基本機能

    • 作成
      • テンプレートに定義された構成でスタックを自動作成
      • 並列でリソースを作成し依存関係がある場合は自動的に解決
    • 変更
      • スタックに前回のテンプレートとの差分を適用(冪等性)
      • リソース変更時は 無停止変更 / 再起動 / 再作成 のいずれかが発生
      • Change Set を作ることで差分の内容を事前に確認可能
    • 削除
      • 依存関係を解決しつつリソースを全て削除
      • データストアはスナップショット取得 / 保持が可能
  • CloudFormation スタック

    • 1つのスタックの出力値を別のスタックに提供することで、スタック間を連動させてインフラを構成することが可能になります。
    • スタック間で情報を共有するにはスタックの出力値をエクスポートします。
    • スタックの出力値をエクスポートするには、スタックのテンプレートの Output セクションの Export フィールドを使用します。
    • CloudFormation スタックに既存のリソースをインポートすることが可能です。
    • これはエクスポートされた出力値を別スタック側が利用する際に使われます。
  • CloudFormation ドリフト
    • テンプレートを利用してインフラ展開後にインフラ構成に変更が発生した場合のテンプレートと展開されたコードとの相違点です。
      • 実際のリソースとCloudFormationテンプレートの内容に乖離があることをドリフトと言います。
  • CloudFormation スタックセット
    • 利用するとCloudFormation テンプレート内に AWS リソースの設定を定義して、1つのテンプレートにより複数の AWS アカウントやリージョンにリソースを展開できます。
    • クロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップにこの機能を活用できます。
    • 一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。
  • CloudFormationテンプレート
    • テンプレートからAWSリソースを自動構築するための一連のセット様式のことです。
  • CloudFormation 変更セット
    • CloudfFormationのテンプレート内容の変更を行う仕組みです。
    • スタックを更新する必要がある場合は、変更の実装前に実行中のリソースに与える影響を理解することで、安心してスタックを更新できます。
    • 変更セットを使用すると、スタックの変更案が実行中のリソースに与える可能性がある影響 (たとえば、変更によって重要なリソースが削除されたり置き換えられたりしないか) を確認できます。

CloudTrail

  • AWS インフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持できます。
  • AWS CloudTrail はAWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。

AWS Config

  • Configでは、AWS リソースの設定が継続的にモニタリングおよび記録され、望まれる設定に対する記録された設定の評価を自動的に実行できます。
  • AWS ConfigはAWS リソースの設定を評価、監査、審査できる構成管理のサービスです
  • 何に対して、誰が、いつ、何をしたかを自動で継続的に記録し、確認する

AWS OpsWorks

  • クラウド企業内のアプリケーションを設定および運用する環境自動化サービスです
    • 個別にSSH, RDPログインして設定が不要になったりなど..
  • 以下の機能を使用する
    • Puppet
    • Chef

MSecurity, Identity & Compliance

Amazon Cognito

  • API ベースで実装されるモバイルアプリや Web アプリにユーザ認証機能を提供するサービス
  • MFAによる多要素認証と保存データおよび転送データの暗号化が実施できます。
  • また、GoogleFacebookAmazon などのソーシャル ID プロバイダーや、SAML による Microsoft Active Directory などのエンタープライズ ID プロバイダーを通してサインインすることができます。
  • Amazon Cognitoはウェブアプリケーションおよびモバイルアプリに素早く簡単にユーザーのサインアップ/サインインおよびアクセスコントロールの機能を追加できます。

Amazon Inspector

  • Amazon EC2にエージェントを導⼊し、プラットフォームの脆弱性を診断する、ホスト型診断サービスです
  • Amazon Inspector は自動化されたセキュリティ評価サービスで、AWS にデプロイしたアプリケーションのセキュリティとコンプライアンスを向上させることができます
  • 自動化されたセキュリティ評価サービスで、自動的にアプリケーションを評価し、露出、脆弱性、ベストプラクティスからの逸脱がないかどうかを確認します。

CloudHSM

  • シングルテナント方式のFIPS140-2 Level3準拠のハードウェアセキュリティモジュール(HSM)を使用した暗号鍵管理サービス
  • AWS CloudHSMを利用した鍵管理により、EUなどの各国の厳しいセキュリティ基準を満たすことができます。
  • AWS CloudHSMは安全なキーストレージや高パフォーマンスの暗号化オペレーションを AWS アプリケーションに対して簡単に追加できるようにするクラウドベースのハードウェアセキュリティモジュール (HSM) です。
  • AWS CloudHSM では不正使用防止策が施された HSM へのシングルテナントアクセスを利用できます。HSM は暗号化モジュール向けの FIPS 140-2 レベル 3 標準に準拠しています。

AWS KMS

  • マルチテナント方式のマネージド暗号鍵管理サービス
  • 暗号鍵の作成、管理、運用のためのサービス
  • KMIは2つの機能から成り立つ
    • 鍵の保管
      • 鍵を安全に保管するストレージ
    • 鍵の管理
      • 鍵のライフサイクル管理、及び鍵の管理や利用に対する認証・認可・記録するアクセス制御

AWS Shield

  • マネージド型のDDoS攻撃に対する保護サービスで、AWS で実行しているアプリケーションを保護します。

AWS WAF


Analytics

Amazon Athena

  • Amazon S3 にあるデータ(およびさまざまなデータソース)に対して標準 SQL を使用して簡単に分析可能とするインタラクティブなクエリサービス
  • 実行するクエリに対してのみ料金が発生し、各クエリでスキャンされるデータ量に基づいて課金されます。
  • データの圧縮、分割、列形式への変換を行うと、大幅なコスト削減とパフォーマンス向上を実現でき、データ処理コストを抑えることができます。

Amazon EMR

  • 大幅なコスト削減を可能にする、クラウドを利用したマネージドなHadoopとSpark
    • Hadoop
    • Spark
      • ビッグデータ処理ツール
      • インメモリ高速分散処理プラットフォームで、大規模データ処理用統合分析機能を提供します。「高速」かつ「汎用的」であることを目標に設計されています

Amazon Kinesis

  • ストリームデータを収集・処理するためのフルマネージドサービス群
    • センサーデータを処理する(IoTなどで使用)
  • Amazon Kinesis Data Analytics ストリーミングデータをリアルタイムで分析することができますが、本件では適用できません。これはIoTなどのストリーミングデータを対象としており、画像解析データなどの解析には不向きです。

Amazon Kinesis プラットフォーム

  • Amazon Kinesis Data Firehose
    • ストリーミングデータをデータレイクやデータストア、分析ツールに配信するサービスです。
    • ストリーミングデータをキャプチャして変換しつつ、Amazon S3Amazon Redshift、Amazon Elasticsearch Serviceにロードします。
  • Amazon Kinesis Streams
    • ストリームデータを処理するためのアプリケーションを独自に構築
    • Kinesis Data Streamsは一連のデータレコードを持つシャードのセットであり、各データレコードにはKinesis Data Streamsによって割り当てられたシーケンス番号があるため、 メッセージが失われず、重複されず、到着と同じ順序で伝送することが可能です。
  • Amazon Kinesis Analytics
    • ストリームデータを標準的な SQL クエリでリアルタイムに分析

Redshift

  • Redshiftは高速でシンプルかつ費用対効果の高いデータウェアハウスサービスです。
    • おもにBIや業務データ分析に利用します。ユーザー行動データの高速な処理には向いていません。
  • スナップショットの要領で課金

拡張VPC ルーティング

  • Redshiftクラスターに対する拡張VPCルーティングを有効にすることで、VPCに出入りするRedshiftクラスターのすべてのCOPYおよびUNLOADトラフィックを監視することができます。
  • Redshiftは拡張VPC ルーティングを使用すると、Redshift はクラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックVPC を通るよう強制します。
  • 拡張された VPC ルーティングを使用することで、 VPC セキュリティグループ、ネットワークACLVPC エンドポイント、VPC エンドポイントポリシー、インターネットゲートウェイドメインネームシステム (DNS) サーバーなどのスタンダード VPC 機能を使用することができます。

Work Load Management

  • RedshiftのWLM(Work Load Management)を利用することで、クエリ処理を実施する際に、クエリ処理をキューとして実行順序を定義することが可能です。
  • WLMはRedshiftのクエリ処理に対して割り当てるRedshiftのリソースを指定する機能です。
  • 事前にWLMとしてキューを用意しておき、キューに対して割り当てるメモリの割合や並列度、タイムアウトの時間を指定することでクエリに対するリソース配分を決定したり、長時間実行されるクエリを止めてクラスタリソースを無駄遣いしないようにすることができます。

Redshiftスペクトラム

  • 利用することで、S3バケットに保存されたデータを直接分析することができます。

Mobile

API Gateway

  • Amazon API Gateway は簡単にAPI の作成と管理が可能となる完全マネージド型のAPIサービスです。
  • ユースケース
    • インターネットからアクセス可能なパブリックなWeb APIの基盤を提供する
    • ⾃社企業・企業グループ内でのプライベートなWeb APIの基盤を提供する
    • AWSサービス(例:Amazon DynamoDB 等)を独⾃のWeb API化する⼿段として利⽤する
    • サーバーレスアーキテクチャを実現する⼿段として利⽤する
  • API Gatewayはグローバルおよびサービスコールを含むさまざまなレベルでスロットルを提供します。
  • ロットリング制限設定はリクエストが多すぎるために バックエンドサービスが処理しきれなくなることを防ぎます。
    • たとえば、API所有者は自分のREST APIの特定のメソッドに対して毎秒1,000リクエストのレート制限を設定し、数秒間で毎秒2,000リクエストのバーストを処理するようにAmazon API Gatewayを設定することもできます。
    • Amazon API Gatewayは1秒あたりのリクエスト数を追跡​​し、制限を超えたリクエストは429 HTTPレスポンスを受け取ります。
  • Amazon API Gatewayキャッシュをプロビジョニングして、そのサイズをギガバイトで指定することで、API呼び出しにキャッシュを追加できます。
  • キャッシュは、APIの特定の段階用にプロビジョニングされています。これによりパフォーマンスが向上し、バックエンドに送信されるトラフィックが減少します。
  • キャッシュ設定を使用すると、キャッシュキーの作成方法と各メソッドに保存されるデータの有効期間(TTL)を制御できます。
  • API Gateway はLambdaと連携してサーバレスアーキテクチャーを構築する際に頻繁に利用されます。
  • API Gatewayトラフィック管理、認可とアクセスコントロール、モニタリング、API バージョン管理など、最大数十万規模の同時 API コール処理が可能です。
  • API Gateway には最低料金や初期費用はなく、受信したAPI コールと転送データ量に応じて課金されます

AppSyn

  • リアルタイム機能とオフライン機能を備えたフルマネージド GraphQL サービス管理やスケールを気にせずに使える
  • AppSyncを使用して、DynamoDBのデータをリアルタイムで最新の状態に保つコラボレーションアプリを簡単に構築できます。
    • これにより、アプリケーションはAmazon DynamoDBのデータにアクセスしたり、EC2インスタンスAWS Lambda関数がデータ処理を実行するなどの機能を実装することができます。
    • したがって、DynamoDBとAppSyncとを連携して、リアルタイム処理機能を実装することが可能です。

Application Integration

Amazon SNS

  • Amazon SNS には、代表的な機能として Mobile Pushとpub-sub 機能があります。
    • Mobile Push (プッシュ通知)
      • モバイルアプリが起動していなくても通知。
      • モバイルユーザは通知を受け取るか否か選択可能。
      • 通知をきっかけにアプリを起動してもらう。
    • pub-sub
      • 通知もできるが、分散アプリケーションの統合用途に用いられる。
  • メッセージングが主要な役割であり、特定のイベントをトリガーにワーカープロセスを起動する構成に利用します。
  • アプリケーションは「プッシュ」メカニズムを使用して、複数のサブスクライバーにタイミングが重要なメッセージを送信することができます。そのため、更新を定期的に確認したり、「ポーリング」する必要性がなくなります

SQS

  • SQSはアプリケーションコンポーネント間で転送されるメッセージを生成・管理する信頼性が高く拡張性の高いマネージドメッセージキューサービスです。
  • SQSはキューによってシステム処理を分散させて負荷分散を可能にします。
  • これはAWSリソースの水平方向のスケーリングに役立ちます。
  • SQSキューによって複数EC2インスタンスによる並行処理が可能となり、負荷分散や処理プロセスの最適化を達成することができます。
  • FOFOキュー
    • FIFOキューを利用することで高スループット、ベストエフォート型の順序付け、少なくとも1回の配信を可能にします。
    • FIFOキューはメッセージ順序を保証し、少なくとも1回のメッセージ配信をサポートしています。
  • メッセージ重複排除 ID
    • SQSはメッセージ重複排除 IDを利用することで重複メッセージを防ぐことが可能です。
    • メッセージ重複排除 IDは 送信されたメッセージの重複排除に使用するトークンです。
    • 特定のメッセージ重複排除 ID を持つメッセージが正常に送信された場合、5 分間の重複排除間隔の間、同じ ID を持つ送信メッセージは配信されません。

AWS Step Functions

  • AWS Step FunctionsはAWS の複数のサービスを利用して、サーバーレスなワークフローに構成できます。これはワークロードの作成・管理に利用されるものである
  • 分散アプリケーション・マイクロサービスの全体を「ステートマシン」と呼ばれる仕組みでオーケストレートできる
  • 定義したステートマシンは AWS コンソールから「ワークフロー」(右図) という形式で見やすく可視化できる
  • ステートマシンの各ステップの実行履歴をログから追跡できる

Customer Engagement

Amazon SES

  • 利用することでEメール機能を実装することができます。
  • アプリケーションの利用ユーザーに対して一斉メールによるお知らせを実施するといった使い方をします。
  • メール送信
  • メール受信
    • S3バケットに自動的に配信できます。
    • メッセージ受信時にLamdaを使用してカスタムコードを実行することや、特定のワードを含むメールを受信時に SNSを使って通知を配信することができます

Other

AWS Import / Export

  • 物理ストレージデバイスからAWSに大量のデータを転送するために使用できるサービスです

Amazon Elastic Transcode

  • 動画のトランスコード処理のジョブはパイプラインがリクエストを受信した順に処理が開始されます。ジョブの変換プロセスでは、入力ファイルサイズ、解像度、ビットレートなど多くの変数が変換速度に影響します。
    • 例えば、 iPhone 4 プリセットを使用した10 分の動画のトランスコード処理時間は約 5 分です。Amazon Elastic Transcodeが多数のジョブを受け付けると、ジョブはバックログ (キュー) に登録されます。

DLM

  • Amazon Data Lifecycle Manager (Amazon DLM)を使用するとEBSのバックアップであるスナップショットの作成、保存、削除を自動化できます。 定時バックアップをスケジュールして貴重なデータを保護します。
  • Amazon Data Lifecycle Manager (DLM)を使用するとEBSのスナップショット作成や削除をスケジューリングすることができます。DLMを利用することで次のような設定が可能となります。
    • EBSの定期的なバックアップスケジュールを実施して貴重なデータを保護する。
    • 監査担当者または社内のコンプライアンスが必要とするバックアップを保持する。
    • 古いバックアップを削除してストレージコストを削減する。

AWS Budgets

  • AWS Budgets には、カスタム予算を設定して、コストまたは使用量が予算額や予算量を超えたとき (あるいは、超えると予測されたとき) にアラートを発信できる機能が用意されています。
  • これはAWSの利用コストをリアルタイムで把握するためのモニタリングツールである

AWS Data Pipeline

  • AWS Data Pipeline は、データの移動と変換を自動化するサービスです。
  • AWS Data Pipeline はデータ駆動型のワークフローを定義して、タスクの正常な完了をトリガーにして、次のタスクを実行できます。
  • AWS Data Pipeline はDynamoDBに設定することが可能であり、定期的なデータ取得タスクを設定させることができます。

AWS STS

  • AWS Security Token Service (AWS STS) を使用して一時的セキュリティ認証を付与することができます。

ACM

  • SSL証明書を集中管理するためのAWSサービスとしてAWS Certificate Manager(ACM)を利用します。
  • ACMAWS サービスとユーザーの内部接続リソースで使用するパブリックまたはプライベートの SSL/TLS 証明書を作成・登録・管理することができます。
  • SSL/TLS 証明書を設定すると、SSL認証が利用されHTTPS通信によりネットワーク通信が保護されます。
  • AWS Certificate Manager を使用すれば、SSL/TLS 証明書の購入、アップロード、更新という時間のかかるプロセスを手動で行う必要がなくなります。

AWS SAM

  • AWS SAMは、サーバーレスアプリケーション構築用のデプロイツールです。
  • YAMLを使用して、サーバレスアプリケーションのLambda関数、API、データベース、イベントソースマッピングモデリングします。
  • AWS SAMはCloudFormationと連携してサーバレスアプリケーションを展開します。
  • その際は、SAM が SAM 構文を AWS CloudFormation 構文に変換および拡張することで、サーバーレスアプリケーションの構築を高速化することができます。

AWS SWF

  • Amazon SWF はステップまたは連続したステップがあるバックグラウンドジョブを構築、実行、スケールすることができるクラウド内の完全マネージド型の状態トラッカーおよびワークフローシステムです。

Active Directory


補足

タグ

  • 最大数 50
    • キー : 127文字
    • 値 : 255文字

侵入テスト

  • 8つのサービスでAWSの許可なく侵入テストを行うことができる

iSCSI

ストレージをSCSIでネットワーク接続 ストレージゲートウェイができる

暗号化

  • 法に相互に排他的な3つのオプションがあります。
    • Amazon S3管理キーでサーバーサイド暗号化を使用する(SSE-S3)
    • AWS KMS管理キーを使用したサーバーサイド暗号化を使用する(SSE-KMS)
    • 顧客提供のキーを使用してサーバーサイド暗号化を使用する(SSE-C)

SSE-S3

  • SSE-S3はAES-256暗号化を使用した暗号化方式です。
  • Amazon S3 で管理された暗号化キーにより実施されるサーバーサイド暗号化です。
  • ユーザーがキーに対するアクセス管理はできませんが、署名バージョン4によりアクセス制限が設定され、所有者であるAWSアカウントID以外からのアクセスを拒否します。
  • SSE-S3は暗号化と復号化をS3が自動で実施してくれるため最も管理に手間がかからない暗号化方式である

SSE-C

  • ユーザが管理する鍵により暗号化を実施できます。
  • これにより、S3上に置かれたコンテンツを柔軟に保護できるようになります。
  • ユーザーが用意した暗号化キーでのSSE-Cを使用すると、独自の暗号化キーを設定できます

SCP(Service Control Policy)

  • SCPは組織に含まれる複数のAWSアカウントに対してざっくりとした権限制御を行うための仕組みです
  • OU(組織単位)
    • OUに対してSCPはデフォルトでフルアクセス権限が付与されており、ホワイトリスト形式のSCPが付与されても、他のリソースに対してフルアクセス権限が継続されます。

IAMデータベース認証

  • EC2インスタンスがIAMデータベース認証を利用してDB インスタンスにアクセスが可能です。
  • この認証方法では、DB インスタンスに接続するときにパスワードではなく、認証トークンを使用します。
  • 認証トークンはAmazon RDS がリクエストに応じて生成する一意の文字列であり、AWS 署名バージョン 4 を使用して生成されます。
  • トークンには 15 分の有効期間があります。
  • 認証トークンは IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。

ROA

  • Route Origin Authorization (ROA) は、RIR を介して作成されるドキュメントです。
    • 地域インターネットレジストリ (RIR、Regional internet registry)
      • 五つの地域インターネットレジストリ(RIR)では、 リソース証明書とROAが提供されています。
  • これには、アドレス範囲、そのアドレス範囲を公開することを許可された ASN、および有効期限が含まれています。
    • ASN(AS番号)とは、ASに一意に振られる番号です。
    • ASとは、BGPという経路制御プロトコルの制御単位であり、ネットワークのカタマリです。
      • BGPについては詳しいことはインターネットを検索すればたくさんの記事が出てきますので、そちらをご参照ください。
  • ROAAmazon が特定の AS 番号のアドレス範囲を公開することを承認します。
  • さらにAWS アカウントに対してアドレス範囲を AWS に持ち込むことを承認するには、アドレス範囲について RDAP の注釈で自己署名付きの X509 証明書を発行する必要があります。
    • Registry Data Access Protocol (RDAP)
      • IPアドレス等のレジストリに登録したデータにアクセスするためのプロトコルで、 WHOISプロトコルの後継として、 RFC7480~7485において標準化されたものです
      • RDAPの主な特徴としては、以下が挙げられ、TCP43番ポートを用いてテキストベースで通信されるWHOISとは異なっています。
        • HTTP(S)にて通信されること
        • 応答がJSON (JavaScript Object Notation)*2形式で構造化されていること
  • 証明書にはパブリックキーが含まれており、AWS はこれを使用してあなたが提供する認証コンテキスト署名を確認します。
  • プライベートキーを安全に管理し、これを使用して認証コンテキストメッセージを署名します。
  • これによって、既存のオンプレミス環境で利用していたホワイトリストAWSに移行することが可能となります。

クラスタープレイスメントグループ

SAML

  • SAML(Security Assertion Markup Language)はインターネット上で、IDやパスワードなどの認証情報を連携するためのXMLベースの仕様です。
  • SAMLは主にエンタープライズアプリケーション間の認証で使われています。
  • SAMLMicrosoft Active Directoryを使用しているため、AWSクラウドへのAPIアクセス用にSAMLベースのフェデレーションを設定できます。
  • AWS Single Sign-Onなどのサービスを利用することで、SAMLによる認証の仕組みを実現することが可能です。
  • AWS SSO は SAML IdP 機能を AWS Managed Microsoft AD または AWS SSO ディレクトリに追加します。
  • それにより、ユーザーは、AWS マネジメントコンソール やサードパーティー製アプリケーションなど、SAML をサポートするサービスへの SSO が可能になります

オンプレとAWSとの接続

Disaster Recovery

  • パイロットライト
    • 利用可能であるアプリケーションの最小バージョンを準備しておくことをパイロットライトのこと呼びます。
    • パイロットライトではサーバーなどセッティングされた構成を他のリージョンなどに準備しておいて、非常に稼働させて利用することができます。
    • パイロットライトという用語は、最小限のバージョンの環境が常にクラウドで実行されているDRシナリオを表すためによく使用されます。
    • AWSでは、AWSでシステムの最も重要なコア要素を設定して実行することでパイロットライトを維持できます。
    • 回復時には、重要なコアを中心に本格的な本番環境を迅速にプロビジョニングできます。
  • マルチサイト
    • マルチサイトの場合は、起動しているサーバー構成を準備して、マルチリージョンやマルチAZ構成を利用する構成のことです
  • バックアップ&リストア
    • これはスナップショットやAMIを別リージョンに保持しておくことです。これは最もコストがかからないDR対応として利用されます。
  • ホットスタンバイ
    • これは稼働可能な状態となっているインフラを準備し、アクティブにするだけで切り替えることができるスタンバイ構成のことです。

AMI

  • Amazon EC2 instance store-backed AMI
    • 使用してEC2インスタンスを作成すると、そのインスタンスのデータはインスタンスストアに保存されます。
    • インスタンスストアボリューム上のデータはインスタンスの存続期間中のみ持続するため、インスタンスが終了するとデータは自動的に削除されます。
    • インスタンスストアはインスタンス用のブロックレベルの一時ストレージです。
    • このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。
    • インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなど) の一時ストレージとして最適です。
    • また、インスタンスのフリート全体でレプリケートされるデータ (負荷分散されたウェブサーバープールなど) にも適しています。

IPフローティング

ARN

  • Amazonリソースネーム(ARN)によりAWSリソースを一意に識別します。
    • IAMポリシー
    • Amazon Relational Database Service(Amazon RDS)
    • タグ
    • APIコール
    • etc ...
  • AWS全体でリソースを明確に指定する必要がある際にはARNが必要です。
  • ARNは以下のような形式で定義されています。