diaryこの広告は、90日以上更新していないブログに表示しています。ワークショップをオンラインで行うというものです。以下のリンクからアクセスできます(言語設定を英語にするとSaaSレンズが確認できます)。aws.amazon.com今まではAPNパートナー向けに開催するケースはそこまで多くなく、2回目(かつオンラインでは初)の試みだったようです。他社の方とワークショップを行う機会はなかなかなく、良かったのでそのレポートです。ワークショップの流れ一週間くらい前に事前に登録を行い、参加しました。ワークショップが行われました。当日は次のようなスケジュールで進行されました。概要について学んでいきました。以下の話が印象に残りました。このタイミングでは4つの柱だった。Frameworkはチェックリストではない情報を提供しているだけで、ユーザは理解したうえで活用して行く必要があります。ベストプラクティスを知った上で、「ビジネス的な判断をする」ための手法。よる監査ではないレビューは一日や数時間で終わるもの(数日かかるようなものは何かがおかしい)。短時間で効率的にディスカッションを行う。いうページで実際にベストプラクティスをハンズオン形式で学ぶことができるとの紹介もありました。柱ごとに100・200・300といったようにレベルが設定してあるので、とっつきやすいと思いました。www.wellarchitectedlabs.comお昼休憩の時間では少し長めに休憩を取り、資料の読み込みも行いました。資料は午後からディスカッションを行うための仮想顧客のアーキテクチャを説明したものです。この資料を基に午後のディスカッションが進行していきます。午後からはグループに分かれてディスカッションを行いました。トピック11つ目のトピックは運用上の優秀性の柱でした。設計原則は次の5つです。運用をコードとして実行する小規模かつ可逆的な変更を頻繁に行う(定期的なデプロイ)運用手順を定期的に改善する障害を予想する運用上のすべての障害から学ぶこれらの説明を10分程度で解説してもらい、各グループに分かれて20分程度ディスカッションをするという形式で行われていきました。名で一つのグループなり、考慮事項の一つのトピックに焦点を当ててディスカッションを行っていく形です。資料の説明では漠然としていて、(実業務で出くわすような)ざっくりとしていて情報が欠落しているため、様々な角度から議論できるようになっている題材でした。トピック22つ目のトピックはセキュリティの柱でした。設計原則は次の7つです。行うセキュリティイベントを把握するのがまず大事でそのあとに分析を行っていく必要があるという話もありました。Service)は初めて知りました。入れている企業も多いという話を伺いました。検知(発見的統制)はあるので、発見後に封じ込めることが必要であるという話もディスカッション中に出てきました。Detective(インシデント調査)、Macie(機密情報の検出・保護)などのサービスはあるので、レビューをしていくうえで足りない部分をサードパーティ製のソリューションで補うのがよいのではと考えました。トピック33つ目のトピックは信頼性の柱でした。一言でいうと、「期待されるタイミングで、意図した機能を正確かつ一貫して実行するワークロードの能力(ライフサイクル全体を通してワークロードを運用及びテストする機能が含む)」です。設計原則は次の5つです。AWS-CDK)人の手ではなく環境を立てることができ、ヒューマンエラーを排除できるトピック44つ目のトピックは信頼性の柱でした。一言でいうのと、「システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力」のことです。設計原則は次の5つです。簡単に環境を立てて実験できるようになっているシステムに対する精通の程度を考慮する最新のテクノロジーのメリットもあるが、リスクもあるので、無理に新しいから使うのではなく、勉強したうえで利用するまた「昔のアンチパターンが時ともに変化する。アンチパターンがそうではなくなった話を思い出しました。トピック5最後のトピックは信頼性の柱でした。設計原則は次の5つです。消費モデルを導入する全体的な効率を測定する差別化につながらない交付かの作業に費用をかけるのを病める費用を分析し、帰属させる感想(意図的に)色々な突っ込みどころを持ったアーキテクチャや概要説明であったので、グループメンバとのディスカッションを広がりを持ってやることができてとても有意義でした。3つ目のトピックくらいから疲れてきましたが、他社さんの話や自分の中になかった考え方を知れて勉強になりました。匿名でメッセージを投稿できて、SAの方にほとんど拾っていただけたので、ざっくばらんな内容のメッセージも投稿できたのがよかったです(「やりたいけど、できてないです」というのは匿名だといいやすかったです)。ディスカッション中にもSAの方がファシリテートしてくれたので短い時間でしたが活発に議論できて、あっという間にワークの時間が過ぎていきました。内容が良かったので、次回があったら同僚にようと思います。実業務で同僚が使っているのを見たことしかなかったので、今度自分で触る機会を作ってみようと思いました。セキュリティ(SCS)に合格しました前回の試験から間が空いてしまいましたが、あの後2週間おきに立て続けにDOPとSCSを受験してきました。範囲ということもあり追加で勉強をして、試験に臨んでみました。シリーズを触る(ある程度知っておいた方が人に説明する際の紋所になって仕事がしやすくなる)ため、資格を取得しておいた方がいいと思ったということもあります。試験勉強としては、模擬試験をバウチャーを利用して受験、その後全問見直しと理解をしていくというスタイルで臨みました。Codeシリーズがテスト範囲としてあり、あまり理解が進んでいなかったので、実際に手を動かしてパイプラインを作成してみました。試験当日コロナで東京には行きにくくなってしまったので、車で行ける範囲を選択しました。厚手のマスクを着用していったら途中で意識が朦朧としてきてテストの問題が大変だったというより酸素を確保するのが大変でした。全問解き終わったのが残り10分くらいで軽く見直しをしてタイムアップ。結果は844点である程度余裕をもって合格できました。問題文が何を一番問うているのかと、勝手に文脈を補わないという点が自分なりのコツでした。いう書籍も評価がよかったのでこちらを利用して勉強をしながら、対策を進めました。サービスがまとめられていて、巻末には練習問題がありました。受けるようにしています。週末に勉強をして、平日の人があまりいない時間に試験を受けるという算段です(ここ二か月毎回同じ時間に試験を受けに来ているので顔を覚えられてしまった可能性があるかもしれません)。試験の問題自体は170分で65問なので、プロフェッショナル試験よりも時間に余裕がありました。30分くらい残して全問解ききり、フラグを付けたところを見直しました。肌感としては800点くらいは取れたのではと思いましたが、結果は762点。あと一問間違えていたら落ちていました。オンプレADとのインテグレーションやIAMとリソースのアクセスコントロールの優先順位が詳細までわかっていないなど、知識の粗が目立つ感じでした。試験内容はAWS以外の部分でも利用できる箇所はありますが、AWSなしでどうするかであったり、実戦経験はまだまだひよっこなのでこれからも学び続けていきたいと思います。プロフェッショナルに合格しましたSAP試験に合格しました。1月くらいからちょっとずつ勉強してきて、今月やっと受かったのでどんなことをしてきたのか書き残したいと思います。やったことまず自分の立ち位置を知るためにAWSの模擬試験を受けてみました。勉強すれば行けるかなと思いました。読めば頭に入るタイプではないので、過去の記事のようにそれぞれのサービスの説明を書きながら整理していきました。コースを購入して演習テストを解いて、解説を読みつつ知識を補強していきました。www.udemy.com内容は、本番試験に比べてマニアックなものが多く、個人的には2回りくらい難しかったような気がします。全5回の演習を終えても7割はおろか、6割を超えることもできず、かなり凹みました。かかっているのに点数が全く伸びませんでした)。こちらのコースを全て終えて、点数が思ったようにならなかったので、気分を変えるために(点数がある程度出て自信をつけるために)こちらの対策本を購入してやってみました。問題の難易度としては本番にかなり近いと思います。こちらの問題と振り返りをして、さらに最初に受けたAWSの模擬試験の間違えた問題を振り返りました。ここでの振り返りはノートに書き込んでいく古典的なスタイルで勉強していました。一通りできることはやり尽くした感があり、点数が足りている訳ではないですが、ここで一回受けてみようということで受けてみました。電車ではなく、車で行ける試験会場を選びました。自分の一番の不安は3時間、トイレに行けず、冷房にあたり続けることだったので、当日はパーカーを持参して、最低限の水分をとって臨みました。試験官に聞いたところ、途中でトイレに行くことはできるみたいですが、試験時間は進むとのことでした。徐々に体温が奪われていきましたがなんとか3時間耐えることができました。試験自体は1時間で25問を解くペースで進めないと間に合わないのですが、少し遅れ気味で、最後の問題を解き終わった時には残り10分程度しかありませんでした。問題文が何を聞いているのか(もっともスケールする、であったり、コスト最適化など)によって答えが変わってくるので普段以上に注意しながら読んでいったため、時間に追われることになりました。試験問題は演習問題でやってきた問題より日本語が怪しく、英語版を読みつつ回答していきました。試験の詳細の点数なども当日中に返ってきました。割くらいの得点で合格することができました。www.youracclaim.com他の人に比べて時間はかかってしまいましたが、合格できてよかったです。後日談SAPに合格した流れでDVAにも受験してきました。前日にバウチャーを利用して模擬試験を受けたところ55点だったので危ういなと思いました。問題の間違った箇所を重点的に見直しをして、当日臨みました。手応えはなく、慢心してしまったかと思い、後悔していましたが9割程度の得点で合格できていました。問題文の日本語訳は結構ひどく、問題文の一番重要な部分が丸ごと抜け落ちているというものもありました。DVAは合格はできたものの知らないことが多く、運がよかっただけな気がするので、実際に何かものを作ってそのあとに試験を受けるのがいいのかなと思いました。モバイルアプリの開発を加速させるプラットフォーム。行ってくれることで、価値のある部分に集中することができる。複数環境の構築やそれを利用したテストまではカバーされている。記述することでカスタムカテゴリとして利用できるようになるみたいだが、用法用量は守ったほうが良さそう。返し配信A/BテスティングメッセージのA/Bテスト最大5つのメッセージを作成し、どれだけの割合で送るかを決められる。RDSに入っている個人データからターゲットを抽出しS3に保存。分析のマネージドサービス。利用するよりこちらを利用することを推奨している。面白かったのは速報&非速報パターン。サーバレスでスケールするので一斉に送りたくなってしまうが、そうすると一斉に大量のユーザーが流れ込んでしまうのでアプリの設計次第ではサーバが落ちてしまいかねない。いう時に非速報パターンでユーザの動きを制御することで大量のユーザにキャンペーンを流しつつも、サーバーがダウンして体験を損なわないということができる。A/Bテストなどの実験しやすい機能も揃っていて、どんな時にユーザーの反応がいいかを試せるのはかなりいい機能だと思った。マネージド、サーバレスBIサービス。いうインメモリデータベースでデータの分析が行われるがデータ量に気をつけないといけない。人数ベースで課金が発生するので運用の設計はきちんとしておかないと結構お金がかかるように感じた。BIツールであるので、特定の人に公開されたWebサイトでグラフィカルにカスタマイズされたUIを提供するのが主といった感じ。機械学習や分析をする際にデータレイクのデータはそのままでは利用できない。それを可能にするためにデータカタログを作成する必要がある。ETL処理を行い、他のAWSサービスが分析をできるようにするサービス。これだと部分的にしかできずに他のサービスのセットアップも必要になる。課金はETL処理をするためのリソースと各種サービスの料金がかかる。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。