AWSの認定試験2つ取ってみた

仕事上AWSを使うことが増えており、どうせなのでお勉強がてら資格を取ってみた。

Solution architect associate

とりあえずAWSのサービスでどんなものがあって、どんなことができるかはすべて押さえてみた。 サービスの名前と、それらがどんなことを叶えてくれるのかが１行で説明できるようなレベルでまずは浅〜くお勉強した。

そのあとはデザインパターン本（設計と実装）を読んででてきたサービスについてホワイトペーパーを読んで自分なりにまとめた。 さらにAmazon Web Services パターン別構築・運用ガイドも最後まで目を通した。

で、模擬試験を一旦受けてみたところ6割くらいで不合格。。。

VPCやEC2の深い部分への理解が足りていなかったのでそこら辺を再度洗い直した。

合格したのは1/29だった。

Amazon Web Services パターン別構築・運用ガイド

Ａｍａｚｏｎ　Ｗｅｂ　Ｓｅｒｖｉｃｅｓ　クラウドデザインパターン設計ガイド　改訂版

Amazon Web Services クラウドデザインパターン実装ガイド　改訂版

Developer associate

こちらは本やホワイトペーパーでの学習は行わなかった。

ちょうど英語の勉強をしていること、Udemyが大幅なディスカウントをしていたこともあってこれを受講した。

www.udemy.com

10時間くらいの動画講義だったので朝ちょっと早く会社に行って動画見てというのをちまちま積み重ねてお勉強してみた。 最後まで通して見て、模擬試験を受けたところ9割ほど取れていたので、速攻で予約して受験した。

結果3/12に89%で合格することができた。

日本語ではこういう動画見つけられなかったので英語できると色々と捗るなと感じた。

次は今年新しく始まる情報セキュリティマネジメント資格を取って、それからSysAdminを受けようと思う。

AWS Cloud Roadshow

KeyNote1 普及期に来たクラウド。安心して企業に導入するためのポイント

去年は大阪で1000人のエントリ。今回は1300人を超えるエントリ。

クラウドとはIT利用の新しい形

キャズムを超えて普及期に入ったAWS=>2014年時点で25%の企業が利用中

Amazonのサービスを以下の観点から支えるために生まれたのがAWS

• スケール
• スピード
• UX

AWSと同じことはやろうと思えば自前でもできる。 でも皆さんのやりたいことはそんなことじゃないはず。=>「価値をお客様に届ける」ことにAWSの顧客を集中させる

クラウドに踏み出せない方々の声

ICT白書によるとクラウドサービスを利用しない理由として以下の3つがよく挙げられる。

• 必要がない(今のままで回ってるし業務)
• セキュリティに不安(どうなの？)
• クラウドへの移行コスト(どうなの？)

必要がないと思う人たちへ

2つのアプローチでAWSの利用を促進している。

カイゼン的アプローチ

御社のITを楽に早く安く実現できますよ

イノベーション的アプローチ

今までできなかったことができるようになりますよ

例えばソラコム

ソラコムはAWSを使ってフルクラウドな通信事業基盤を作っているので、他の通信事業者よりも格安なSIMが提供できている。 =>AWSを使うことで安くサービスが提供できるようになった。

セキュリティに不安を感じている人たちへ

導入後企業の多くがクラウド化することでセキュリティが向上するという感想を持つことが多いことがアンケートで分かっている。

なぜ？

• データセンタの冗長化
• 脆弱性への早期対応
• 数多くの第三者認証

災害対応などのために冗長化は必須だが自社でやろうとすると複数のDC契約して、それぞれを管理するというのはとっても面倒だし大変。

脆弱性対応のパッチをAWSのエンジニアが当ててくれるので早期対応ができ、自分でやる必要がない。

第三者認証もこれだけのものを自社で取得するのは大変だ。

移行コストが大変と思っている人たちへ

VPCを使って閉域網を構築できるし、専用物理サーバーを提供することもAWSではできるようになった。 すぐに試せる仕組みがあるので、とりあえず試してみましょうよ。

AWSのソリューションアーキテクトや多数のパートナーがお手伝いできます。

最後に

なぜクラウドにするとコストが下がるのか？

Sony銀行の公開している資料で詳しく説明がされているのでオススメ。

クラウドは失敗のコストを低減できる

オンプレミスでハードウェア買ってとかやってたら失敗した時に大きな損失につながる。

クラウドであれば最小限のコストで済む。

失敗のコストが下がれば挑戦のコストが下がるのでビジネスを加速させることができる！

コードネーム U.N.C.L.E見ました

コードネームU.N.C.L.E見ました。

あ、テレビ版は見たことないです。

結構面白かった！

一番良かったシーンはソロがワインを飲みながらボートを眺めてるあのシーンですねw 船の光がカメラの方に向いて強まるたびに、笑ってしまいました。

しかも裏で流れている音楽が謎にガラスの部屋。

歌詞の意味を調べてみましたが「月は私たちと共に連れ添っていた」とかあって、月が出てたかもしれないなあのシーンそういえばとか思いました。

まあ歌詞はいなくなってしまった恋人への歌って感じなんですけどね。

こういう印象に残るあのシーンみたいなのがあるとやっぱりいいなーと思います。 ただ、そういう意味ではキングスマンの威風堂々のあのシーンには少し劣るかなーと思ってしまったのが残念。

まあでもキングスマンでもそうですけど、やっぱりスパイはスーツがいいですねー。 スマートな感じというか理知的な感じが出てていいです。まあガンガン銃打ったりするんですけどね。

ありがちな裏切りの例の展開も後から考えると伏線というかなんというかが貼られてていい感じです。 ネタバレになるので説明できませんが、普通そこまで××！って思ってたところが解決しました。なるほどそりゃそうだわ、と。

ソロとイリヤのキャラが正反対に立っていたのでそれも良かったです。 ソロはスーツでプレイボーイ、イリヤはカジュアルでチェリー感。 細かい技術に得意不得意があって、装備の質に差があったりして。 でも同じ目的のために力を合わせて戦って、イリヤは過去のトラウマに打ち勝って、最後には2人で酒を飲み交わすっていう。

あ、最後の展開でチームが結成されたわけですが次回作もあるんですかねー あったらいいなーと思います。あのチームの活躍をもっと見てみたい。

スパイ映画は今年3本目できっと来週あたり4本目のスペクターも見ると思うので楽しみです。

キングスマン(字幕版)

デザインパターンと共に学ぶオブジェクト指向のこころ 第6章

Facadeパターン

Facadeとは見せかけという意味の単語です。 このパターンは複雑な既存システムを自分たちのプロダクトとうまく連携させるための方法を示しています。

複雑な既存システムを簡潔に呼び出せるようなインタフェースを用意するというパターンです。

こうしておくことでクライアント側は簡潔にシステムを呼び出せるようになります。

また、カプセル化によって既存システムのアップデートの際に影響を受ける範囲を限定的にできます。

Facadeパターンを使うと、既存システムに外から新たな機能を擬似的に持たせることもできます。

例えば既存システムの呼び出し回数を記録するような機能を追加したいとした場合、すべてのシステム呼び出しをFacade経由で行わせるようにしつつ、呼び出し回数をFacadeの中でカウントするような仕組みを作るだけで実現が可能になります。

デザインパターンと共に学ぶオブジェクト指向のこころ001

第1章：オブジェクト指向パラダイム

オブジェクト指向を説明するために手続き的な方法とオブジェクト指向を対比して解説をしています。

オブジェクト指向以前のパラダイムであった手続き的な方法は機能分解と表現されており、機能に着目して メソッドを分解していくやり方として説明がされています。

実生活において複雑な問題に取り組むときは問題を小さい範囲に切り分けて小さく小さく解決していくという方法はよくある方法であり、それが有効な手段であることは実生活を送る中でイメージがつきやすいし、単純明快なので、楽です。 なので、易きに流れるという意味で、何にも考えずに開発を進めていくと手続き的になってしまうのは当然のことなんだということがわかりました。 なんとなく感覚として持っていたものですが言葉にされると腑に落ちる感じがしますね。

ただ、ソフトウェアの要求は絶えず変更されることが常であり、手続き的な方法だとその変更に柔軟な設計にならないという点が問題です。なのでオブジェクト指向を学びましょうねということです。

移譲や責任についての話がその後に出てきているのですが、Martin Fowlerのソフトウェア開発における3つの視点の話を知らなかったので学びになりました。

• 概念：私は何に対して責任があるのか？という視点
• 仕様：私はどのようにして使用されるのか？という視点
• 実装：私はどのようにして自身の責任を全うするのか？という視点

概念レベルでそれぞれのオブジェクトが正しく会話するように設計することで低い結合性や高い凝縮性が実現できるようになるわけですね。

3つの観点からオブジェクトを見ると以下のように説明することができる。

• 概念：オブジェクトは責任の集合である
• 仕様：オブジェクトはその他のオブジェクトや自らを起動することができるメソッドの集合である
• オブジェクトはコードとデータ、そしてそれらの相互演算処理である

DDD本を第2部まで読んでみて

ここまで読んでみて現場の業務でよく使われているDDD的な語彙をカバーすることがある程度できたように感じています。

エンティティやリポジトリなど設計の上で出てくるユビキタス言語を実感を持って理解できるようになったかなと感じています。

本文の中でも触れられていましたが、ユビキタス言語の中にはこのようなDDD用語も含まれており、DDDに取り組むチームの全てのメンバーはこれらを共有できてないといけないと思います。

そういう意味でやっと出発点に立てたのかなと思っています。

一方で、学べば学ぶほどもっと根本にあるオブジェクト指向やデザインパターンについての理解が大切であることも強く感じるようになりました。

ということで並行してオブジェクト指向やデザパタについても深く学んでいきたいとおもいます。 取り急ぎ以下の本をタイトルに惹かれて購入しました。

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

DDD本の学習とここへのアウトプットは継続しつつオブジェクト指向とデザパタについても並行で学んでいきたいとおもいます。

エリックエヴァンスのドメイン駆動設計を読んでいる(第2部 第7章)

DDDの実践例

この章では貨物輸送会社のためのソフトウェアを例に挙げてDDDの実践例を示している。

気になった箇所を抜粋して考えてみる。

ドメインを隔離する:アプリケーションの導入

アプリケーションクラスは調停役であり、調停役は自分で出した質問に対する答えを出してはいけない。 答えを出すのはドメイン層の仕事である。

これはレイヤーの責務に関する内容。アプリケーション層はUI層とドメイン層を結ぶ薄い層であるべきで、 アプリケーション層には脳みそを持たせないというような表現がうちの現場ではされています。

エンティティとバリューオブジェクとの区別

配送記録

配送記録は他の配送記録と区別されるのでエンティティである。しかし、配送記録には貨物と一対一の関係があり、 配送記録単体での一意性は持っていない。配送記録は貨物の一意性から借用することになる。

エンティティであってもルートではない場合はグローバルな一意性はいらないということの例だと思います。

位置

位置のような基本的なエンティティは多くの理由から多数のオブジェクトによって使用される可能性があるので出来るだけ責務を小さくしておいたほうが使いやすい。

集約の境界

独自の同一性を持つものはそれぞれが独自に集約を持ち、そのルートとなる必要がある。

リポジトリの選択

リポジトリを持ちうるエンティティはルートのみであるため、リポジトリ候補は５つにあらかじめ絞れる。

どのリポジトリを実装するかについてはアプリケーションの要求に立ち戻って考える必要がある。

ここはかなり重要で、あまり理解できていなかった頃はとりあえずルートエンティティに対しては無邪気にリポジトリを作ったら良いと考えていました。 しかしそれでは意味がなくて、どのように使われるのか？どのようなことがドメイン層に求められるのか？を考えながら設計をしていくと、リポジトリが不要なエンティティも少なからずあるということを頭に置いておきましょう。

2つのシステムを接続する

異なるシステムを自身のシステムに接続する場合、自身のプロジェクトで用いているユビキタス言語に支障をきたす恐れがある。 これを防ぎ、かつ接続元のシステムから自身のシステムで必要な要素だけを取り出せるようにする薄皮的な層を腐敗防止層と言い、14章で詳しく説明があるようだ。