1 Minute Tips

投稿者: sumito.tsukada

  • go言語でファイルを書き出す

    go言語でファイルを書き出す

    はじめに

    ファイルを開き、書き出す方法

    自分用メモ

    コード

    package main

import (
	"fmt"
	"io/ioutil"
	"log"
)

func main() {

	// file open
	content, err := ioutil.ReadFile("main.go")
	if err != nil {
		log.Fatalln(err)
	}
	fmt.Println(string(content))

	// file 書き出し
	if err := ioutil.WriteFile("tmp", content, 0755); err != nil {
		log.Fatalln(err)
	}
}

    結果

    $ ls -l /Users/sumito/go/src/github.com/GitSumito/go-sample/tmp
-rwxr-xr-x  1 sumito  staff  306  5 14 00:00 /Users/sumito/go/src/github.com/GitSumito/go-sample/tmp
$

     

    golang の新書

  • go言語でのstringやint、structのsort

    go言語でのstringやint、structのsort

    はじめに

    どの言語でも一発でsortするメソッドは用意されているものだが、あまり馴染みのない言語だと時間がかかるものだ。
    go言語でのsortについてまとめる。

    以下、自分用メモ。

    コード

    package main

import (
	"fmt"
	"sort"
)

func main() {

	i := []int{5, 3, 2, 8, 7}
	s := []string{"c", "a", "z"}

	p := []struct {
		Name  string
		Point int
	}{
		{"AAA", 50},
		{"BBB", 40},
		{"CCC", 10},
		{"DDD", 20},
	}

	// Intをsort(昇順）
	sort.Ints(i)
	fmt.Println(i)

	// stringをアルファベット順にsort
	sort.Strings(s)
	fmt.Println(s)

	// structをStringでsort (名前順)
	sort.Slice(p, func(i, j int) bool { return p[i].Name < p[j].Name })
	fmt.Println(p)

	// structをIntでsort (昇順）
	sort.Slice(p, func(i, j int) bool { return p[i].Point < p[j].Point })
	fmt.Println(p)

}

    出力結果

    [2 3 5 7 8]
[a c z]
[{AAA 50} {BBB 40} {CCC 10} {DDD 20}]
[{CCC 10} {DDD 20} {BBB 40} {AAA 50}]

     

    golang の書籍

    golang の書き方ではなく、お作法を学ぶことができる良書。

  • 「これ以上やさしく書けないプロジェクトマネジメントのトリセツ」を読んだ

    「これ以上やさしく書けないプロジェクトマネジメントのトリセツ」を読んだ

    はじめに

    エンジニアの傍らプロジェクトマネジメントのお仕事をさせて頂き始めて１年が経った。

    右も左も分からずもがきながら進んで来たが、ちゃんとしたプロジェクトマネジメントの本を読んだ事がなかったので、まずは一冊。最もやさしそうな本から読み始めようと思い、「これ以上やさしく書けないプロジェクトマネジメントのトリセツ」を手にとった。

    本記事の読者対象

    • プロジェクトマネジメントを始めたが進め方が不安な人
    • 「図解これ以上やさしく書けないプロジェクトマネジメントのトリセツ」に興味を持っている人

    どのような構成か

    プロジェクトをまわしていくストーリーが展開されている。

    プロジェクトマネージャは進め方に悩みながら進めていくが、そこでプロジェクトマネジメントの「先生」が現れ、課題を解決していく。

    このような構成なので、読者はプロジェクトマネージャの立場で読む事ができ、問題の解決策を「先生」から学ぶ事ができる。

    ストーリーがベースのため非常に飲み込みやすい構成になっている。また、登場人物はわずか７人のため、読んでいて混乱することもなく、プロジェクトマネジメントの理解に集中できるよう工夫もされている。

    この本（これ以上やさしく書けないプロジェクトマネジメントのトリセツ）のスコープ

    一口に「プロジェクトマネジメント」と言っても、プロジェクトマネージャの仕事はとにかく多いが、計画立案から、終結までの進め方がこの本のスコープに当たる。

    主に企画・計画立案・社内決済・基本設計・システム開発など、プロジェクトの成果が生まれるまでの一連の流れを開設されてある。

    以下、私がこの本を読んで行った中のメモになる。

    プロジェクトとは

    そもそもプロジェクトとは

    特定目的を達成するための臨時組織による活動。
    目的がなければプロジェクトは不要。
    目的が曖昧であれば必要なプロジェクト活動ができない。

    プロジェクト開始時に最低限必要なもの

    • 企画書、計画書
    • プロジェクト体制図、スケジュール表

    プロジェクト完了後の姿を明確にする

    プロジェクトが終了した時点で、具体的に何がどうなっているのか。　
    具体的な効果。明確なゴールがないと、ミーティングの話しがまとまらなくなる。

    プロジェクトマネジメントとは

    プロジェクトを先読みする技術。いかに先読みして、手戻りが発生しない最善の手を打っていくか。

    先読みの技術の１ツールとして

    • WBS（Work Breakdown Structure）
    • PERT（Program Evaluation and Review Technique）
    • リスクマネジメント

    が存在している。中でもWBSは最も重要。

    WBS

    プロジェクト活動に必要な全作業を、管理可能な単位に階層的に分割。作業のもれや、ダブりを最小限に抑える事ができる。

    作業の一つ一つを分解し、誰でも理解できる大き際に細分化する。
    細分化する事で具体的に何をすればいいかが見えてくる。

    PERT

    所要時間と前後関係を明確にする役割がある。
    最も重要なことは、最短経路（クリティカルパス）を導き出すことにある。

    リスクマネジメント

    損失を発生するかもしれない不確実な度合い。まさかの事態が起きないよう、事前に対策を講じる必要がある。

    • 損失発生を未然に防止するためにリスクを低減させる
    • 損失が発生してしまったら、被害を最小に食い止める
      　先手を打つ、事前に対策を考えておくなど。

      リスクの洗い出しはブレインストーミングが有効。
      洗い出したら、リクスを評価、優先順位を５段階で決める。

    ステアリングコミティとは

    プロジェクトの講演会のような存在。

    プロジェクトオーナーと、リーダの中間。必須ではない。

    企業におけるプロジェクト

    • 経営改革プロジェクト
      　経営戦略の策定
      　経営理念の確信
      　組織革命（グループ経営、組織改革など）
      　事業の再構築（リストラ、M&Aなど）
      　運営構造の確信

    • 商品＆事業開発プロジェクト
      　新規商品開発や、研究開発など。
      　多角化などの新規事業開発も含まれる。

    • 情報システム開発プロジェクト
      　情報システム再構築

      上記３つをマネジメント系プロジェクトと呼んでいる。

    • プラント建設プロジェクト
      　工場の建築や、都市開発などがこれにあたる。

    プロジェクトマネジメントの必要性

    大半のプロジェクトは（プラント建設プロジェクト以外は）経営資源（ヒト・モノ・カネ・情報）の投資対効果を最大化する事。

    プロジェクトと既存業務との違い

    既存組織の特徴

    現状の枠組みを維持、組織の秩序を守る事が最大の勝ちにつながる

    既存組織の目的

    毎年の業務目標の達成。時間軸で業務目標決める

    プロジェクトの留意点

    プロジェクトに属する人のバックグラウンドが違うので、以下を留意する必要がある。

    • 前提条件の確認
      　プロジェクトにおける決め事

    • 制約条件の確認
      　社外要員（法規制、世論からの制約）
      　社内要員（会社の経営資源の大きさ、経営者のこだわりなど）

    • プロジェクトの作業計画、納期とスケジュールの明確化
      　WBSやガントチャート

    • 意思決定としてのオーナーの明確化
      　プロジェクトリーダーはフットワークの軽い人が適任
      　プロジェクトリーダーは、客観性の維持のため、自ら意思決定する事ができない。
      　オーナーは意思決定者

    • ステークホルダーの明確化、配慮
      　ステーキホルダーがプロジェクトを妨害しないために、権威ある人がオーナーになる必要がある。

    まとめ

    まとめると以下の通り

    ポイント既存組織（チーム）プロジェクト
    前提現状の組織
    組織の統制、秩序を重視    		新しいことを始める
    目的業務目標の達成など特定の目的、目標を達成させる
    組織継続的組織
    人事異動を伴う    		臨時組織
    人事異動は不要
    構成員同じ分野のスキルを持つ人数より人材要件を重視
    多様な分野のプロフェッショナル
    業務形態繰り返しのある日常業務繰り返しがない

    やるべき事が明確なものなどは、既存組織で進める方が良い

    何でもプロジェクトでやろうとしない。既存組織での解決するというやり方もある。

    プロジェクトの体制

    以下の２つが大きい。特徴は以下の通り。

    純プロジェクト組織

    特徴

    既存組織から人員を抽出、専任体制で進める形式

    メリット

    専念できるので、プロジェクトの成功率が向上する。
    既存組織のルールでマネジメントを行っても、そこそこうまくいく。

    デメリット

    占有するため、プロジェクトの人件費が固定費になる

    マトリックス組織

    特徴

    既存組織に属しながら、プロジェクトを兼務する方式。

    メリット

    人を増やさないため、即日発足可能

    デメリット

    兼任体制なので、専念できない

    プロジェクトが失敗するパターン

    • 空中分解（途中で終息・解散）
      　周囲のステークホルダ（利害関係者）から協力を得られないなど

    • その場しのぎで「プロジェクトで解決する」と宣言

    • プロジェクトオーナー不在
      　プロジェクトリーダーは実行の責任者だが、
      　プロジェクトオーナーは意思決定者にあたる。そのため、オーナー不在では決められない。
      　オーナー不在では、利害関係から発生する衝突に対応できない。

    • 見切り発車
      　走りながら考えるようになると、ことごとく裏目になる可能性が高い。
      　目的がころころ変更され、やり直しが多発することになる。

    • 丸投げ（営業が一括受注・要件定義不明）
      　うまく行かなかった際、手の打ちようがなくなる。
      　丸投げするのであれば、丸投げ先に計画を立ててもらい、プロセスの見える化が必要。

    • ダボハセ（プロジェクトでやる事が多くなり、首が回らなくなる）
      　あれもやろう、これもやろうでやる事が増えてしまうプロジェクト。
      　本当に必要なテーマに絞り込んで取り込むのが重要になる。
      　戦略論で「選択と集中」が重要

    プロジェクトマネジメントの５原則

    1. プロジェクトフェーズとライフサイクルの原則
      プロジェクトの不確実性を回避するために、プロジェクトは適切なフェーズに分けて実施。そのため、大規模プロジェクトはフェーズに分かれる。

      例えば、
      * 企画フェーズ（問題解決のためのテーマの設定）
      * 基本設計フェーズ（全体構造を明らかにして、全体と部分の関係を明確にする）
      * 詳細設計フェーズ（詳細な仕様設計・コスト積算まで行う）
      * 調達開発フェーズ（具現化させる）
      * 導入・運用フェーズ（プロジェクトの効果を得る）

      プロジェクトが長期にわたる場合、中だるみしがちになる。メリハリをつけるためというのも理由の一つ。

      プロジェクトの開始と終結（ライフサイクル）を明確にする必要がある。ライフサイクルは、立ち上げ、計画、実行、コントロール、終結のプロセスから成り立つ。

    2. ステークホルダー明確化の原則
      プロジェクトの影響を受ける全ての人がステークホルダーとなる。
      ステークホルダーに対してプロジェクトの位置付けを明らかにし、協力者になってもらう必要がある。

    3. 組織影響の原則
      どのように影響を与えるのか明確にする。
      ここを明確にしないと既存組織から反感を買う恐れがある。

    4. プロジェクト運営知識・能力確保の原則
      プロジェクト運営に必要な知識能力を備えている必要がある。
      プロジェクトマネジメントの知識を有し、プロジェクト計画や実行に活かされる必要がある。

    5. 社会経済的影響の原則
      一つのプロジェクトが時には社会経済にも影響を与える事を肝に銘じる

    PMO（プロジェクトマネジメントオフィス）の役割

    大きく３つの役割を持たせる

    1. 全社レベルでのプロジェクトのリソースマネジメント
      全社のリソース配分を最適化し、パフォーマンスの最大化を目指す

    2. プロジェクトのストップ＆ゴーの決断
      重要度が低いものはストップさせ、重要度の高いプロジェクトに再配分する

    3. プロジェクトマネジメントのノウハウの定着
      社内でプロジェクトマネジメントの研修を実施し、共通のノウハウとして全社に定着させる。

    PMBOK

    プロジェクトマネジメントの知識体系。世界で通用するプロジェクトマネジメントのデファクトスタンダード。

    以下の９つで構成される

    1. 統合マネジメント
    2. スコープマネジメント
    3. タイムマネジメント
    4. コストマネジメント
    5. 品質マネジメント
    6. 人的資源マネジメント
    7. コミュニケーションマネジメント
    8. リスクマネジメント
    9. 調達マネジメント

    まとめ

    私がメモを取ったのは以上の通り。プロジェクトマネジメント初心者にとっては非常にわかりやすくイメージもしやすいように纏まっている。

    辞書的に使いたいような素晴らしい本だった。

  • SCRUM BOOT CAMP THE BOOKを読んだ

    SCRUM BOOT CAMP THE BOOKを読んだ

    はじめに

    SCRUMのプロジェクトに属した事がなかったので、スクラムのスの字も分からなかった。

    しかし、色々な方々と話している時にSCRUMの言葉が出て来てついていけなくなった事があった。

    自分のチームがスクラムを導入するわけではないけど、スクラムというのはどうゆうものなのか概要は知っておくべきだなと思い、本書を手に取った。

    本記事の対象者

    • SCRUM BOOT CAMP THE BOOKに興味を持っている人
    • SCRUMを知らない人

    どのような本か

    SCRUMはアジャイル開発の一つ。

    現場の人たちの持てる力を最大限に引き出すための必要な事がまとまっているフレームワーク。

    ストーリーは漫画がベースになっていて、登場人物が色々問題にぶつかっていくが、SCRUMチームが解決していく。シンプルな話を通じて、具体例がわかりSCRUMがだいたいどんなものなのか理解できるようになる構成になっている。

    よって、以下の人が本書の読者対象として設定されているようだ。

    • 全体像と決められているルールについて理解したい人
    • 自分の現場でうまく取り入れていくためのヒントを得たい人

    本書の構成

    大きく二つ。スクラムの概要が約20ページでシンプルにまとまっており、実践編が約200ページと手厚くなっている。

    得られる知識

    SCRUMの概要

    SCRUMのルールは細かく決まっているものがあるが（例えばなぜスプリントの期間は一定でなければいけないのか）、それについてなぜそのようなルールが決まっているのかが説明されている。

    それが２時間程度で読めるボリュームに収まっている。

    自分のように直ぐに業務では使わないが、最低限の概要を知りたいという人にとってSCRUM入門の最初の一冊目に読んでよかった。

    本書の足りない所

    残念ながら索引がない。なので、せっかく分かりやすい良書ではありつつも、辞書的に使う事ができない。SCRUMの用語がどのページに出て来るのか、本の最後に欲しかった。

     

  • Go言語での正規表現

    Go言語での正規表現

    はじめに

    Go言語内の文字列の判定で正規表現を使う際の“regexp”ライブラリについてまとめる

    使い方

    MatchString

    正規表現のフォーマットに沿った文字列か確認し、True/Falseを返す

    	match, _ := regexp.MatchString("b([a-z]+)a", "banana")
	fmt.Println(match)

    結果

    true

    しかし、この書き方では複数の文字に対してチェックしたい場合、都度正規表現を書かなくてはならない。

    MustCompile

    以下の書き方をすることで正規表現の定義は一度のみでよくなる

    	r := regexp.MustCompile("b([a-z]+)a")
	ms1 := r.MatchString("banana")
	fmt.Println(ms1)
	ms2 := r.MatchString("apple")
	fmt.Println(ms2)
	ms3 := r.MatchString("orange")
	fmt.Println(ms3)

    結果

    true
false
false

    FindString

    MustCompileの中でURIを正規表現で定義し、
    FindStringで、そのルールに収まっているか確認をするという使い方もできる。
    	r2 := regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
	fs := r2.FindString("/view/test")
	fmt.Println(fs)

    結果

    /view/test

    もしヒットしない場合は、結果を返さない。

    FindStringSubmatch

    格納されるデータはスライスで入っているので、一つ一つ取り出すことも可能。

    	fss := r2.FindStringSubmatch("/view/test")
	fmt.Println(fss[0])
	fmt.Println(fss[1])
	fmt.Println(fss[2])

    結果は以下の通り

    /view/test
view
test

     

  • プロダクションレディマイクロサービスを読んだ

    プロダクションレディマイクロサービスを読んだ

    はじめに

    オライリーのプロダクションレディマイクロサービス（原書: Production-Ready Microservices ）を読んだ。

    本記事はその書籍を通してえられた事についてまとめた。

    本記事の対象者

    • マイクロサービスに興味を持っている人
    • プロダクションレディマイクロサービスに興味を持っている人

    なぜ読もうと思ったか

    ４月からマイクロサービスで動いている共通基盤チームを担当することになり、今まではなんとなくマイクロサービスについて理解はしていたが、きちんと書籍を通して学んだ事がなかったので、比較的時間の作りやすいゴールデンウィークの課題図書として読み、ブログを記載する事で理解を深めようと思った。

    本書を通して何を得られたか

    マイクロサービスのメリットはそれなりに知っていた。大きなところだと、システムを疎結合にする事により、変更の容易性を得られる事にあると思っていた。

    その前提の状態から本書を読み、得られたポイントは以下の通り。

    ドキュメント

    マイクロサービスを導入すると技術的負債が増える傾向がある。本書によると、一種のトレードオフとされてある。

    その対処法を要約すると、ドキュメントの維持・管理とメンバーの理解にあるという。組織的に明確化され、構造化されていれば技術的負債を引き起こす混乱や、意識の欠如、アーキテクチャの理解の欠如を払拭する事ができるとのこと。

    確かに、自分もドキュメントはマイクロサービスでなくても重要であり、しかし更新が後手後手になってしまい陳腐化してしまうプロジェクトやチームを多数見てきた。

    なお一層、ドキュメントを最新にしチームで共有するというのが必要になりそうだ。

    ドキュメントのポイントは以下の通り

    • 包括的か
    • 定期的に更新されているか
    • マイクロサービスの説明、アーキテクチャ図、連絡先、オンコールの情報、重要情報へのリンク、サービスのリクエストフロー、エンドポイント、依存関係、FAQなど盛り込まれているか
    • ドキュメントがチーム内でよく理解されているか
    • 簡単に検索できるか

    注意すべきはREADME。これは本番対応のドキュメントではない。

    組織的な理解

    チーム内の全ての開発者がマイクロサービスの本番対応についての質問に答えられ事ができるかが重要になる。

    マイクロサービスのレビュー、監査は頻繁に行われる必要がある。

    本番対応の監査プロセスも確立されている必要がある。

    成長の判断基準

    サービスがサポートできるRPS（毎秒平均リクエスト数）、QPS（毎秒平均クエリー数）を尺度とする。

    将来サービスに必要とされるRPS/QPSがどれくらいになるかを予想する。

    この指標は量的な成長の判断基準を決めるときの判断材料になる。

    しかし、RPS/QPSの情報は、成長の判断基準を初めて計算した時のマイクロサービスの状態に左右される事が多い。

    マイクロサービスは単独で動いているわけではなく、大きなエコシステムの一部として動いているという事を念頭に置く事が重要。

    マイクロサービス内のプログラムは何でも良いのか

    並行性とパーティション分割（タスクがただ小さな部品に分割されているだけではなく、並列処理できるようにする事）を実現しようとし、非同期フレームワークを使いたい場合、並行性とパーティション分割のために構築された言語である、C++、Java、Goなどが望ましい。仮にPythonでサービスを書くと、スケーラビリティやパフォーマンスを妨げる無数のボトルネックが作られ、それらの悪影響を緩和するのが困難になる。

    並行性とパーティション分割は、相乗効果でマイクロサービスのスケーラビリティとパフォーマンスに影響を与える。

    監視の主要なメトリック

    ホスト、インフラ周り

    • CPU
    • MEMORY
    • スレッド
    • ファイルディスクリプタ
    • データベース接続

    これらの監視はモノリシックなアーキテクチャでも定番だ

    マイクロサービスの主要メトリック

    • 言語固有メトリック
    • 可用性
    • SLA
    • レイテンシ
    • エンドポイントの成功
    • エンドポイントのレスポンス
    • エンドポイントのレスポンス時間

    上記の通り、マイクロサービス単体の外形監視が特に必要になる。

    これらをダッシュボードにまとめれば、チーム内で共有しやすくする。

    ダッシュボードは、わかりやすいか、主要メトリックがまとまっており、ダッシュボードを見ただけでマイクロサービスが正しく動作しているか、などが表現されているかが重要になる。

    読み終わって感じた事

    担当しているマイクロサービス基盤チーム内対応できてないポイントが、すべき理由とともに明確になった。

    いきなり全ては難しいので、優先順位を決めてチーム内で話し合って、現実的な所から改善して行く必要がある。

     

    本書はどの現場でも利用できそうな、汎用的なチェックリストも用意されており、チェックリストから読んでいっても、読者の環境をベースにイメージする事ができると思う。

     

  • AWS Solutions Architect受験記録

    AWS Solutions Architect受験記録

    はじめに

    AWS ソリューションアーキテクト（アソシエイト）を合格する事ができた。

    振り返りも兼ねて、まとめたいと思う。

    きっかけ

    ４月AWS Certified Solutions Architectを取得しようと心に決めた。

    理由は以下の通り。

     

    • 入社以来ずっとインフラチームにいたが、４月からマイクロサービスを推進する別チームを担当することになった。今まで仕事を通じて学んだ事を形にしたかった。
    • インフラチームを離れると言っても、AWSを使わなくなる訳ではない。むしろ、積極的に活用する立場になる。どのような構成で設計していけば良いのか、今回の勉強で新たな視点を得たかった。
    • さらなる運用費削減の構成を学ぶ事で、ランニングコストを削減に貢献したいと思った。
    • 今から作ろうとしているシステムの構成で、ベストプラクティスを学べる事ができるかも。
    • 本試験を通じて得られる知識をチームに還元し、チーム全体のレベルをあげるキッカケが作れるかも。

    勉強前の状態

    仕事を通じ、会社のシステムをAWSへ移行するプロジェクトを担当させていただいた。

    ただし、チームで取り組んだので、自分が全てを担当した訳ではない。

    正直言うと、他のメンバーが担当したところは「そーゆーものなのかー」程度だった。

     

    チーム全員がほぼAWS未経験。2つの国を横断するサーバーをAWSに移行した話。

    このプロジェクトではクラスメソッドさんに数々の有益なアドバイスを戴いた。やっぱクラメソさんすごいよ。

    何の教材を使ってどのくらい勉強したか

    定番の黒本

    勉強時間は10時間程度だったと思う。

    この本が特に役立ったのは、S3のバケットタイプ。

    とりあえずスタンダードやGlacierを使っていたけど、それ以外のタイプはあまり詳しくなかった。

    仕事ではバックアップしたファイルをS3に格納したりしているが、今回得た知識を使って去らなくコストダウンをする事ができそうだ。

    その他、EBS最適化、DynamoDB アクセラレーター、他アカウントとの統合など参考になった。

    問題集

    とにかく隙間時間に勉強したかったので、スマホでも勉強できる教材が欲しかった。ヤフオクに売ってる380問くらい入っているのを買った。

    正直結構難しい、「このレベルが実際の試験の問題なのかも」と思い面喰らった。

    なので、とにかく正解率が9割を超えるくらいやり込んだ。おそらく20時間は費やした。

    しかし、実際の試験ではここまで難しい問題は出なかった。

    Udemy

    UdemyでAWS取得コースがあったので、セール中に買って隙間時間にやったが、小テストがスマホ（私がiPhone 7だからか？）に対応していないようで、小テストの度にPCで行なっていたが、次第に億劫になってしまい、最初の５時間程度やっただけでやらなくなってしまった。しかし、コンテンツ自体はとても良質なので、いい教材だとは思う。

    だけど、自分としてはセミナーをじっくり聞いてテストを解くというよりは、テストを先に解いて分からないところを講義を聞くというスタイルじゃないと、眠くなってしまう体質なので自分にはあわなかった。

    https://www.udemy.com/aws-associate/

    AWS Blackbeltの資料

    おそらく3時間程度。

    EC2,VPC,RDSなど、移行の時に使ったり、日々使っているものについてはザーッと流して読んだ程度。

    逆にKinesisやRedshiftは業務で使っていないので、概要を掴んだ。

    Kinesisのチューニングポイントなど、Blackbeltを目を通すだけでも有益だ。

    勉強のアウトプット

    手前味噌ながらメモをサービス毎に本ブログで書いた。

    自分があらかじめ知っていたところは記載しておらず、知らなかったところ、もしくは理解が乏しいところを読み返すためにまとめた。

    そのため、たった１行の記事もある。。

    https://tsukada.sumito.jp/category/tech/aws/aws-certified-solutions-architect-associate/

    （メモです。間違ってるところあったらごめんなさい、直します）

    実際の試験

    自分があまりに構えすぎていたのもあるかもしれないし、たまたま自分の運が良かっただけかもしれないが、難しい問題はそこまでない。

    問題は日本語でも選べるが、ちゃんと読まないと引っかかってしまうものもある。

    幸い、問題毎に日本語・英語を選べる事ができたので、自分の理解に間違っていないか、日本語・英語の両方で確認した。

    試験時間は130分もある。この確認をしても時間は十分に余った。

    試験後の感想

     

    昔Ciscoの試験やOracleの試験を受けた際は「合格・不合格」の紙はもらえたが、それがなかったので全く実感がわいてない。５営業日にメールで連絡来るらしい。

    また、試験の翌日、AWS認定サイトにログインしたら無事合格証のPDFをダウンロードする事ができた。

     

    参考情報

    AWS Solutions Architectを取得するだけでなく、AWSについて体系的に学ぶことができるのでおすすめ。

  • Trusted Advisor

    Trusted Advisor

    カテゴリーの提供情報

    • Performance
    • Cost optimization
    • Security
    • Fault torelance

     

  • ElasticCache

    ElasticCache

    Web sessionデータをリレーショナルデータベースに格納する代わりに、Amazon ElasticCacheを使用する利点

    • セッションデータの読み取り・書き込みパフォーマンスの向上
    • データベースインスタンスの負荷軽減
  • DynamoDB

    DynamoDB

    概要

    ユーザセッション状態を格納する事など可能。耐久性と低レイテンシを備えた構造化ストレージ

    ユースケース

    • Web sessionの管理
    • JSONオブジェクトの保存
    • Amazon S3 オブジェクトのメタデータの保存

    EC2インスタンスにデプロイされたアプリケーションがDynamoDBテーブルに書き込むため必要な作業

    • DynamoDBテーブルへの書き込みを可能にするIAMロールの作成
    • IAMロールを含む起動設定でEC2インスタンスを起動