NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

Configの大量課金リスクと自動化のリスクへの具体的な対策

 こんにちは、大林です。JAWS-UG朝会 #63 で、「ガードレールの有用性とリスク対策」というタイトルで登壇してきました。ガードレールはアカウントを安全に運用する上で実装しておきたい仕組みですが、必ず理解しておくべきリスクもあります。本ブログでは、JAWS-UG朝会 #63で発表した内容を説明していきます。

jawsug-asa.connpass.com



発表資料

speakerdeck.com


アカウント運用のあるべき姿

 上の図は、AWSアカウントを安全かつ効率的に運用するための4つのプロセス、「検知・通知」「調査・修正」「分析」「改善」を示しています。これらのプロセスを循環的に行うことで、継続的なセキュリティ強化と運用の効率化を実現します。
まず、「検知・通知」では、AWSガードレールを利用してポリシーからの逸脱やセキュリティリスクを検出し、即座に通知を行います。次に、「調査・修正」では、通知された内容を確認し、問題の原因を特定してリソースや設定の修正を行います。
その後、「分析」のフェーズで、検知された問題の傾向や頻度を分析し、繰り返し発生している根本的な原因を把握します。
そして最後に、「改善」では、分析結果を踏まえて具体的な対策を実施し、同じ問題が再発しないよう運用ルールやシステム設定を見直します。
このように、単発的な修正ではなく、改善サイクルを回し続けることで、セキュリティリスクを削減し、安定したAWSアカウント運用が実現されます。


アカウント運用におけるコスト増加

 理想的な運用を目指してAWSアカウントの管理や改善を進める際に、意図せず運用負荷が増加してしまう場合があります。「理想」では効率的でコスト削減につながる運用を描いていますが、「現実」では運用が複雑化し、必要な人材やコストの増加に直面することが多いというギャップが存在します。この課題を克服するための一つのアプローチとして、自動化の仕組みを導入することが考えられます。


アカウント運用の自動化によって発生するリスク

 自動化の一例として、AWS WAF(以下 WAF)の自動化に伴うリスクについて説明します。この仕組みは、WAFのログを分析し、例えば異常なリクエスト頻度のIPアドレスを自動的にIPセットに登録するものです。 この仕組みのプロセスは、Amazon EventBridge(以下 EventBridge)でAWS Step Functions(以下 StepFunctions)を起動させ、Step Functions内のLambda関数でAmazon AthenaのAPIを実行してAmazon Simple Storage Service(以下 S3)に保存されたログをクエリで分析し、IPセットを更新する流れを示しています。この自動化により、これまで手作業で行われていたIPリストの更新を効率化し、人材が他の重要なタスクに時間を割けるようになります。
しかし、自動化された処理が意図しないIPアドレスを誤ってブロックしてしまうインシデントが発生する可能性があります。その結果、インシデント対応に追われて、人手不足になったり、お客様からの信用を失うことになります。そのため、自動化は小さく始めていく必要があります。


小さく自動化を進める

 WAFのIPセットを更新するプロセスにおいて、「小さく自動化を進める」アプローチを説明します。具体的には、遮断対象のIPアドレスを運用担当者が判断した上で、手動でそのIPリストをS3にアップロードするところまでを人間が行い、それ以降の更新作業は自動化する仕組みを構築する方法です。このプロセスでは、EventBridgeがS3へのアップロードイベントを検知し、Step Functionsをトリガーします。Step Functions内ではLambda関数を活用して、アップロードされたリストを元にWAFのIPセットを更新します。さらに、更新作業の結果はAmazon SNSを通じて運用担当者に通知される仕組みになっています。
この方法により、人間が関与するのは判断と初期入力の部分に限定されるため、効率化が図れるうえに、誤ったIPアドレスを登録するリスクを最小限に抑えることができます。また、完全自動化ではなく運用担当者の判断を残すことで、信頼性と柔軟性を確保することができます。


ガードレールの大量課金リスク

 AWS Config(以下 Config)は便利ですが、「大量課金リスク」が潜んでいます。Configは環境で繰り返されるリソースの作成や削除を逐一検知し、課金が発生する仕組みです。
特に、IaCを利用している環境では、コードの変更やデプロイのたびにリソースが再生成されるケースが多く、Configがそのすべてのイベントを監視するためにコストが増加しやすい状況が生まれます。この問題により、Configの利用が予想以上に高額な課金を引き起こす可能性があります。例えば、ECSクラスター内で頻繁にコンテナを作成・削除する場合、それに関連するVPCやサブネット、セキュリティグループなども含めてConfigの監視対象となるため、コストが急増します。


ガードレールの大量課金リスク対策

 Configの記録頻度に関するコストとセキュリティのバランスをどう取るべきかについて説明します。Configの記録頻度を「継続的な記録」に設定すると、詳細なリソース変更をリアルタイムに監視できるため、セキュリティ水準を高めることができます。しかし、その分コストが大幅に増加する可能性があり、特に開発環境など頻繁にリソースが作成・削除される環境では注意が必要です。
この問題を解決するためには、Configの記録頻度を「日次記録」や特定のリソースタイプに限定してオーバーライドする方法が最適です。マルチアカウント構成においては、組織全体では「継続的な記録」を維持しつつ、コストが高くなる特定のアカウントに対してのみ設定を変更すると、セキュリティを高い水準に保ちつつ、ある程度の柔軟性を確保することができます。一方で、記録頻度を「日次記録」にや特定のリソースタイプに限定してオーバーライドすると、Configの検知が遅れるリスクが発生するため、そのリスクを受容する必要があります。


大量課金リスクへの予防策

 Configなどのガードレール導入時における大量課金リスクに対する継続的な対応策を3つ挙げて説明していきます。
まず1つ目は、AWS Budgetsを利用して予算を設定することです。アカウント全体や特定のサービスごとに予算を設定し、コストが予算を超過しそうな場合には通知を受け取ることで、早期に対応が可能になります。これにより、想定外のコスト増加を未然に防ぎます。
2つ目は、AWS Cost Explorerを使用してコストの推移を定期的に分析することです。月次や日次のコストデータを視覚化することで、どのサービスが主なコストの要因になっているのかを特定できます。特にConfigの利用に関連するコストが急増していないかを確認することで、効率的なリソース管理が可能となります。
最後に、Amazon CloudWatchを活用して、具体的なメトリクスを監視することが推奨されています。例えば、Configがどのリソースタイプを頻繁に記録しているかを分析することで、記録頻度の調整や不要なリソースの監視対象からの除外といった改善アクションにつなげることができます。


まとめ

 AWSをより多くの人に安全に利用してもらうため、このブログ記事を執筆しました。
AWSは多彩なサービスを提供し、継続的なアップデートで進化を続ける非常に有用なクラウドプラットフォームです。しかし、安全に利用するためには「ガードレール」の実装が欠かせません。
一方で、ガードレールの導入にはコスト増加のリスクが伴う場合があります。ただし、コストの増加は必ずしも悪いことではありません。重要なのは、統制と柔軟性を両立させながら、ケースに応じたセキュリティとコストの最適なバランスを追求することです。このブログで紹介した内容が、皆様のAWS運用の一助となれば幸いです。

『AWS CTO の Articles と見る AWS re:Invent 2020 - 2023』というタイトルで勉強会を開催しました

こんにちは、AWS re:Invent は毎年日本からキャッチアップしている 丹(たん)です。

Japan AWS Ambassadors Advent Calendar 2024の5日目の記事です。

AWS re:Invent 2024 真っ最中ですね。Keynote が始まったところで、アップデート情報キャッチアップ中!!という方も多いのではないでしょうか。

Amazon S3 Tables
Amazon S3 Metadata
Amazon Aurora DSQL
Amazon Nova
Amazon Q Developer
等のGAやプレビュー、アップデートが続々と発表されています。

過去のre:Inventを振り返る意味でも、先月11/19(火)に弊社主催の勉強会にて『AWS CTO の Articles と見る AWS re:Invent 2020 - 2023』というタイトルで登壇しました。
今回は、勉強会の動画・資料を公開するとともに、この会で話した内容をブログでも紹介したいと思います。

動画・資料

動画

www.youtube.com

資料

speakerdeck.com

今回お話したこと

今回は、2020年以降、毎年 AWS re:Invent 前後に AWS CTO が記すテクノロジーに関する予測記事(Articles)に着目して、どのような観点で記されているのか、また、AWS re:Invent で発表されたAWSサービスアップデートと関連があるのかを見てみました。

2024年のre:Invent前には、テクノロジーに関する予測記事はありませんでしたが、再び「Frugal Architect」に着目した記事が公開されています。 www.allthingsdistributed.com

Tech predictions for 2021 and beyond

re:Invent 2020は、AWS re:Invent 開催史上初のフルオンラインで開催されました。(2020/11/30 - 12/18, 2021/1/12 - 1/4)
SpeakerDeckの説明欄に、Keynote動画や資料に載せているURLを記載しています。閲覧したい情報をご参照ください。

■2021年以降のテクノロジー予測
8つの予測それぞれについて、日本語の要約と3つの要点を紹介しました。
※それぞれの予測に関する内容は、登壇資料の「Tech predictions for 2021 and beyond」章をご参照ください

  • 予測1)Cloud will be everywhere
  • 予測2)The Internet of machine learning
  • 予測3)In 2021, pictures, video, and audio will speak more than words
  • 予測4)Technology will transform our physical worlds as much as our digital worlds
  • 予測5)Remote learning earns its place in education
  • 予測6)Small businesses will race to the cloud, and Southeast Asia and sub-Saharan Africa will lead the way
  • 予測7)Quantum Computing starts to bloom
  • 予測8)The final frontier…

ブログでは全ての予測について書きませんが、AWS re:Invent 2020 の主なAWSサービスアップデートと関連性のある(であろう)予測はありました。
Amazon Braketのアップデートと関連があるのは、予測7でした。資料は別途修正しておきます。

AWS re:Invent で発表されるAWSサービスアップデートに関連のある予測もある一方で、2020年のAWSサービスアップデートや後述でも紹介している「NOW GO BUILD!」で、Dr. Werner Vogels 自身が話を聞いたスタートアップ企業のテクノロジーに着目した予測も含まれていました。

Tech predictions for 2022 and beyond

10回目を迎えたre:Invent 2021は、ラスベガスの会場とオンラインで開催されました。(2021/11/29 - 12/3)

■2022年以降のテクノロジー予測
5つの予測それぞれについて、日本語の要約と3つの要点を紹介しました。
※それぞれの予測に関する内容は、登壇資料の「Tech predictions for 2022 and beyond」章をご参照ください

  • 予測1)AI-supported software development takes hold
  • 予測2)The everywhere cloud has an edge
  • 予測3)The rise of smart spaces, especially in senior care
  • 予測4)Sustainability gets its own architecture
  • 予測5)A new wave of connectivity will bring about a new class of applications

Tech predictions for 2023 and beyond

11回目のre:Invent 2022は、ラスベガスの会場とオンラインで開催されました。(2022/11/28 - 12/2)

■2023年以降のテクノロジー予測
5つの予測それぞれについて、日本語の要約と3つの要点を紹介しました。 ※それぞれの予測に関する内容は、登壇資料の「Tech predictions for 2023 and beyond」章をご参照ください

  • 予測1)Cloud technologies will redefine sports as we know them
  • 予測2)Simulated worlds will reinvent the way we experiment
  • 予測3)A surge of innovation in smart energy
  • 予測4)The upcoming supply chain transformation
  • 予測5)Custom silicon goes mainstream

Tech predictions for 2024 and beyond

12回目を迎えたre:Invent 2023は、ラスベガスで開催されました。(2023/11/27 - 12/2)

■2024年以降のテクノロジー予測
4つの予測それぞれについて、日本語の要約と3つの要点を紹介しました。
※それぞれの予測に関する内容は、登壇資料の「Tech predictions for 2024 and beyond」章をご参照ください

  • 予測1)Generative AI becomes culturally aware
  • 予測2)FemTech finally takes off
  • 予測3)AI assistants redefine developer productivity
  • 予測4)Education evolves to match the speed of tech innovation

開催済のre:Capもありますが、AWS re:Invent 2024 re:Cap情報やAdvent Calendarも載せています。

  • AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報

12/6(金)12:00-13:00 ライブ配信予定:https://aws.amazon.com/jp/builders-flash/developer-live-show/#bb

  • re:Invent 2024 Daily re:Cap with AWS Heroes

(終了)re:Invent 2024 Daily re:Cap #1 with AWS Heroes:https://jawsug-chiba.connpass.com/event/335694/
(終了)re:Invent 2024 Daily re:Cap #2 with AWS Heroes:https://jawsug-chiba.connpass.com/event/335704/
re:Invent 2024 Daily re:Cap #3 with AWS Heroes:https://jawsug-chiba.connpass.com/event/335706/
re:Invent 2024 Daily re:Cap #4 with AWS Heroes:https://jawsug-chiba.connpass.com/event/335707/

  • Qiita Advent Calender 2024

Japan AWS Ambassadors Advent Calendar 2024:https://qiita.com/advent-calendar/2024/japan-aws-ambassador
AWS Community Builders Advent Calendar 2024:https://qiita.com/advent-calendar/2024/aws-community-builders

NOW GO BUILD!

人類の困難な問題を解決する革新的なスタートアップテクノロジー企業のストーリーを記録する動画が公開されています。
Dr. Werner Vogels が企業へ足を運び、世界中のイノベーターと会話する姿が見られます。

4つの動画を見ましたが大変興味深いものばかりで、ビジネスのヒントとなるテクノロジーの活用事例もありました。
Season2 Episode2では、Dr. Werner Vogels が日本の高齢化の課題解決に取り組む企業を訪れています。

Season1 Episode1: Financial Health for Smallholder Rice Farmers(HARA Token, Indonesia)
Season1 Episode2: Automating Old Routines(Zimplistic, Singapore)
Season2 Episode1: Bringing Traditional Arts to Life(Zwende, Bengaluru)
Season2 Episode2: The Future of Elder Care in Japan(Z-works/Pixie Dust Technoloties/MICIN, Japan)

Summary, References & Appendix

Summary

  • 2020年以降、毎年AWS re:Invent前後にAWS CTOが記すArticles の内容を見てきました
    • 1年間を通した技術動向から、一部 re:Invent で発表されたAWSサービスにも関連あり
    • 2~3年先(またはもっと先)の技術予測あり
    • 技術動向だけではなく、ビジネスや環境に対する観点での予測あり
  • 過去の re:Invent に関する情報を集めるだけでも多くの時間を要しました
    • 2020年~2023年の re:Invent 情報を参照するのに使ってください
  • 「NOW GO BUILD!」からビジネス観点でのアイディアや発見がありました
    • 世界が抱える困難な課題とそれらの問題を解決するためのテクノロジーは我々に刺激を与えてくれます

References(Dr. Werner Vogels Articles)

References(Others)

Appendix

AWS Pankration 2024 で AWS Developer Experience担当VPの Adam Seligman 氏が登壇していたセッションアーカイブを載せています。 全体として、Seligman 氏は、ソフトウェア開発は消滅することはないが、AI の支援により急速に進化しており、Amazon Q のようなツールがこの変革において重要な役割を果たすだろうと強調しています。

  • JAWS Pankration 2024(実行委員によるニュース)

基調講演は、AWS Developer Experience担当Vice PresidentのAdam Seligmanです!!
https://jawspankration2024.jaws-ug.jp/ja/news/buft--alez6/

  • JAWS Pankration 2024(セッションアーカイブ)

Software Development’s Moment of Change – a view from AWS
https://jawspankration2024.jaws-ug.jp/ja/timetable/TT-37/

今回資料を作成してみて

2020年以降のテクノロジーに関する予測記事をこの機会に読んでまとめることができました。
もう一歩踏み込んで、各記事の深掘りや最新の技術潮流から自身の見解を取り込むところまでいきたかったのですが、今回は集めた情報をまとめるところまでとなります。
また、登壇の機会があればもう少し整理できればと思います。

2024年のアップデートもキャッチアップ頑張っていきましょう!

Japan AWS Ambassador登壇!NRIグループre:Cap 2024~NRIネットコム TECH AND DESIGN STUDY #53~

こんにちは、ブログ運営担当の海野です。
12/23(月)16:00~18:00 当社主催の勉強会「NRIネットコム TECH & DESIGN STUDY #53」が開催されます!!

12月上旬に開催されたAWS最大のカンファレンスであるre:Invent。今年も当社社員を開催地ラスベガスへ派遣して生の情報を仕入れてきました!
今回の勉強会では、Japan AWS Ambassadorの2人が、re:Inventで発表された新機能やアップデート情報に加えて、現地でしか味わえないre:Inventの体験談などもお話しいたします!
また、勉強会後半では、NRIグループ社員8名によるライトニングトークも行います!
re:Inventの情報が盛りだくさんの勉強会となりますので是非ご参加ください!

こんな方におすすめ

  • re:Inventに参加出来なかったがAWSの最新情報が気になる人
  • re:Inventに参加したがキャッチアップを更にしたい人

登壇者

前原良美
株式会社野村総合研究所 シニアテクニカルエンジニア
2024 Japan AWS Ambassador / 2023,2024 AWS Community Builder / 2023,2024 Japan AWS Top Engineer / 2024 Japan AWS All Certifications Engineer

志水友輔
NRIネットコム株式会社 クラウドエンジニア
2023,2024 Japan AWS Ambassador / 2024 AWS Community Builder / 2021,2023,2024 Japan AWS Top Engineer / 2021-2024 Japan AWS All Certifications Engineer

開催日時

2024年12月23日(月)16:00~18:00

開催方式

 ZOOMウェビナー

ハッシュタグ

 #nncstudy

参加費

 無料

お申し込みはこちらから

興味がある方は、是非ご参加ください!

nrinetcom.connpass.com

【re:Invent 2024】認定者ラウンジに入ってみた!

こんにちは、絶賛ラスベガス満喫中の西内です。
まだカジノには手を出していませんが、帰国までにお財布を潤したいものです。

認定者ラウンジとは

re:Inventにてメイン会場で設置されているラウンジになります。
AWS認定資格を保有している人だけが入場できます。
なお、認定資格はPractionerでもProfessionalでも何でもOKです!

入場まで

受付にてCredlyの画面を提示して、入場します。 Credlyはスマホアプリも提供されているので、そちらを入れるとよりスムーズに提示できると思います。

なお、入場受付するとLEGOブロックがもらえました。

ラウンジ内の様子

ラウンジ内にはワーク用の机が複数配置されてました。
人は多めですが、全く座れない超満員とまではいきませんでした。
むしろ席は確保しやすいかと思います。
(写真は撮り忘れちゃいました)

ヘッドホンがたくさん置かれている場所もありました。
KeyNoteの時に音声が流れるのでしょうか。

自分の保有している資格を提示すると、それに対応したシールももらうことが出来ます。
新資格のMLAとAIFがもらえて満足満足。

また、LEGOで先ほどのシールのキャラを作れるコーナーもありました。

こちらの壁の前では、手前のプラカードを持って写真を撮ってもらうこともできます(壁の模様がおしゃれ)。

飲食も充実!
セッション行かずに長居したくなりますね。

ドリップコーヒーも頼むことが出来ます。
注文は壁のQRコードを読み込んで行います。
QRコードを読み込んだ先は...なんとServerlesspresso!  自分も何かのワークショップで構築したことがあるので、実稼働版を使うことが出来て感慨深いです。

Webブラウザから注文を行い、完了すると先ほどのQRコードが書かれた画面の「PREPARING」に自分の番号が追加されて、Webブラウザ上では下の画像が表示されます。

自分の注文が作成開始されると画面が切り替わります。

出来上がるとその旨が画面に表示されて、先ほどのQRコードが表示された画面の「READY」に自分の番号が表示されます。

カフェラテを頼んだのですが、ラテアートもされてました!芸が細かい。。。

なお、このServerlesspressoで費やされる料金も表示されていました。 Amazon SNS以外は無料!!

感想

ラウンジ内が充実していて、とても楽しい区間でした。
何より資格保有者限定というのが何か嬉しいですよね。
セッション間の休憩に便利なので、今後re:Invent行かれる予定のある方はぜひとも一つは認定資格を取得されることをお勧めします。

Looker Studioのデータソースで BigQueryを使用する場合のテーブル設計のポイント

本記事は  【Advent Calendar 2024】  5日目の記事です。
🌟🎄  4日目  ▶▶ 本記事 ▶▶  6日目  🎅🎁

坂本です。
昨年に続いてAdvent Calendarに執筆させていただきます。

※本記事は下記の2023-12-22に投稿した記事の続編になるため、ご覧になっていない方はまずこちらを参照していただけると幸いです。
Looker StudioのデータソースにBigQueryのテーブルを使用する - NRIネットコムBlog

はじめに

Looker StudioでデータソースにBigQueryを使用する場合、(Looker StudioやBigQueryのキャッシュが有効な場合を除いて)レポートを表示する度にBigQueryのクエリが実行されます。 BigQueryのオンデマンド料金ではクエリで処理するデータ量に応じて課金されます。
※BigQueryのクエリの実行(分析)の料金については下記をご参照ください。
料金  |  BigQuery: Cloud Data Warehouse  |  Google Cloud

またクエリで処理するデータ量が多い場合、レポートを表示する時間が遅くなる場合があります。

このためデータソースをBigQueryにする場合、クエリで処理するデータ量をいかに削減するかが重要となります。

集計していないテーブルを使用する場合

以下のようなユーザー数とページビュー数の日毎の推移を表示するグラフを例にします。

集計していないテーブルとして、前回の記事で解説した、Google社が提供しているGA4の一般公開データセット「ga4_obfuscated_sample_ecommerce」を加工したテーブルを使用します。
このテーブルはイベント毎にレコードが作成されており、スキーマは下記の通りとなります。

フィールド 取得する内容
event_date イベントが発生した日付
event_name イベント名
user_pseudo_id デバイス ID(ユーザーを識別するID)
unique_ga_session_id デバイスIDと「ga_session_id(セッションを識別するためのID)」を結合した文字列(※本記事では未使用)
page_location イベントが発生したページのURL(GA4のディメンション「ページ ロケーション」に相当する値)
device_category ユーザーのデバイスの種類(GA4のディメンション「デバイス カテゴリ」に相当する値)

ユーザー数とページビュー数は以下の方法で算出することができます。

  • ユーザー数→デバイス ID(user_pseudo_id )のユニーク数(重複を除いた数)
  • ページビュー数→イベント名(event_name)=「page_view」のレコード数

このため、このグラフを表示する際に実行されるクエリの処理対象のデータの範囲は下記のオレンジ色部分になります。

データ量は下記の掛け算になるため、対象のデータ量が多く利用者数が多いレポートほど注意が必要です。

  • 元のテーブルのデータ量(イベント数)
  • 集計対象とする期間
  • レポートで使用するグラフや表の数
  • レポートの利用者数、利用頻度

この例で使用しているテーブルは1日あたりのユーザー数が約2,000人のWebサイトのもので、1ヶ月分のデータ量が約60MB程度なので問題ないですが、ユーザー数が多いWebサイトのデータを使用する場合は注意が必要です。
例えば1日あたりのユーザー数が約20万人の場合は、単純計算で100倍になるため同様の1ヶ月分のデータ量は約6GBになります。
1年分のデータを表示する場合はさらに12倍になるので約72GBとなり、クエリはグラフや表毎に実行されるため、実際のデータ量はさらに増加します。

※利用者数、利用頻度によってはBigQueryの費用が月間で数十万円以上となる可能性もあります。

集計済のテーブルを使用した場合

データ量を削減する一番効果的な方法は、レポートに最適化した事前に集計したテーブルを使用することです。
※データマートと呼ばれる場合もあります。

例のようなグラフを表示する場合に一番データ量を削減できるのは、下記のような日付毎に集計したテーブルをデータソースとすることです。

このテーブルはどんなに集計前のデータ量が多い場合でも日付毎にデータが集約されるため、レポートを表示する際に処理するデータ量を大幅に削減できます。

ただし、このテーブルは日毎のユーザー数とページビュー数を表示することに特化しているため、下記のような場合には対応できません。

  • デバイスカテゴリ毎に集計する。
  • スコアカードで任意の期間のユーザー数を表示する。
  • 日毎以外に、週、月、曜日毎のユーザー数を表示する。

1つのテーブルでこれらを実現する場合は、下記のような、日付:x_黒太字:デバイスID毎に集計したテーブルを作成することで対応できます。

日付毎のテーブルと比較するとデータ量は増えてしまいますが、日付✖デバイスID毎にデータが集約されるためイベント毎のテーブルよりはデータ量を削減できます。

また下記のように月別にデータを表示する場合は、月別に集計したデータを別途作成することでデータ量を削減できます。

集計済のテーブルを使用するデメリット

集計済テーブルを使用することでデータ量(コスト)を削減できますが、以下のようなデメリットがあります。

  • テーブルのストレージ料金が発生します。
  • テーブルの作成およびデータを更新する対応が必要となります。
  • テーブル(データソース)が多くなるほど、Looker Studioのレポートの設定が複雑になります。特に1つのページに複数のデータソースを使用する場合、ページ共通でコントロール(プルダウン等のフィルタ)を設定することが難しくなります。

まとめ

Looker StudioのデータソースでBigQueryを使用する場合、データソースで使用するテーブルの設計(集計済テーブルの使用)が重要となります。 集計済テーブルをどう使うかは、BigQueryの分析(クエリ)のコストと、テーブルやダッシュボードの作成・維持管理(人)のコストのトレードオフとなります。

データ量が少なく、レポートの利用者・利用頻度が少なくコストやレポート表示速度に問題がない場合は、無理をして集計済テーブルを使う必要はないかと思います。 逆にデータ量が多く、レポートの利用者・利用頻度が多い場合はコストやレポートの表示速度を考慮して集計済テーブルを使用する必要があります。

許容できるコストを意識した上で、状況に応じて最適な方法を検討していただければと思います。

執筆者坂本祐

Google マーケティング プラットフォーム(GMP)を中心とした、デジタルマーケティング関連ソリューションの導入・開発やコンサルティングを担当しています。

【楽しんで考える】AWS BuilderCardsの遊び方!【AWSアーキテクチャ】

本記事は  【Advent Calendar 2024】  4日目の記事です。
🌟🎄  3日目  ▶▶ 本記事 ▶▶  5日目  🎅🎁

はじめに

お疲れ様です。当ブログで技術系の記事以外を書く人 若林です。
年末も近づいてきて帰省の季節ですね。人も集まるタイミングで新しいカードゲームなどはいかがでしょうか?

今回紹介するのは AWS BuilderCards  です。

こちらのルールを教えてもらったので、内容をまとめてみました。

ゲームの説明

AWS BuilderCardsってなに?

  • AWSのサービスでアーキテクチャを組んで得点を稼いでいくカードゲーム。
  • プレイヤーは2~4名、所要時間はおおよそ30~60分程度。

ゴール

  • AWSサービスのアーキテクチャを組んだ際に取得できる Well-Architectedポイントを、一番多く獲得する事。

カードの種類

  • スターターカード(4色)・・・プレイヤーの数だけ必要になるカード(記載されているコメントはユーモアにあふれている)
  • Well-Architectedカード・・・中央に Well-Architectedポイントが記載されたカード
  • ビルダーカード・・・左上の値がオレンジの「AWSビルダーカード」と黒の「通常ビルダーカード」の2種類がある
    BuilderCards

カードの説明

  1. サービス名・・・AWSでのサービス名
  2. 購入コスト ・・・カードを取得(購入)する際に必要なコスト
    コストは以下の2種類
    • AWSコスト・・・オレンジ色で記載された値。AWSクレジットでのみ取得(購入)可能
    • 通常コスト・・・黒色で記載された値。通常クレジットでのみ取得(購入)可能
  3. クレジット ・・・カードを使用した際に獲得できるポイント。これでカードを取得(購入)する
    クレジットは以下の2種類
    • AWSクレジット・・・オレンジ色で記載された値
    • 通常クレジット・・・黒色で記載された値
  4. カードの効果 ・・・カードを使用した際に発動できる効果
  5. カードの属性 ・・・databaseやcontainersといったサービスの属性
    カードの説明

ゲーム場の説明

  1. 通常ビルダーカード山札・・・ビルダーカード置き場からカードが取られたら、ここから補充する
  2. 通常ビルダーカード置き場・・・常に5枚の通常ビルダーカードを置く
  3. AWSビルダーカード山札・・・AWSビルダーカード置き場からカードが取られたら、ここから補充する
  4. AWSビルダーカード置き場 ・・・常に1枚のAWSビルダーカードを置く
  5. Well-Architectedカード・・・すべてのWell-Architectedカードを置く
  6. 共通捨札・・・全プレイヤー共通の捨札置き場
  7. プレイヤー捨札・・・各手番毎に使用したカードを置く
  8. プレイヤー山札・・・プレイヤー毎に持っているカードを置く
  9. プレイヤー手札・・・各手番毎に山札から引いたカードを置く
    ゲーム場

ゲームの進行

準備
  1. 各ビルダーカードをシャッフルし、通常ビルダーカードを5枚、AWSビルダーカードを1枚、各置き場にセット
  2. 参加する各プレイヤーに一人一色ずつスターターカードを配る
  3. じゃんけん等の平和な方法で順番を決める
  4. プレイヤー毎に通常ビルダーカード置き場から好きなカードを1枚取り自分の山札に加える、
    その後、通常ビルダーカード置き場にカードを補充。これを全プレイヤーが3回ずつ実施する。
  5. 自分の山札をシャッフルし上から5枚を手札として引く
ゲーム開始(以下のフェーズを各プレイヤーで繰り返していく)

1. カード廃棄フェーズ

  • 手札の3枚以上がビルダーカードならば、手札のスターターカードから1枚選んで共通捨札においてもよい。
    捨てた場合、4枚の手札で次のフェーズに進む。
    手札の内3枚がビルダーカードなら1枚スターターカードを廃棄可能

2. アーキテクチャ構築フェーズ

  • 手札からスターターカード1枚、もしくは2枚以上のビルダーカードを出す。
    出したカードの各クレジットを合計した値のコストまで、ビルダーカードかWell-Architectedカードを1枚取得できる。
    ビルダーカードを取得した場合はプレイヤー捨札に置く。
    Well-Architectedカードを取得した場合は、手元に置いておく(ゲーム終了時まで各自保管してください)。

    • ビルダーカードを出した場合の追加ルール
      出したカードを全て使ったアーキテクチャを構築し、その説明を行う。
      説明ができたら、出したカードに記載されたクレジットの合計分だけビルダーカードかWell-Architectedカードを1枚取得できる。
      手札からカードを出す

3. エンドフェーズ

  • 出したカード含め、手札を全てをプレイヤー捨札に置き、山札の上から5枚を新たに手札として引く。
    山札が5枚より少ない場合、山札を引き切った後に、プレイヤーの捨札を山札としてシャッフルしてから引く。
ゲーム終了
  • Well-Architectedカードがなくなった時点で、一番多いポイントを持っているプレイヤーの勝利。拍手。お菓子でも買ってあげてください。
アーキテクチャ構築フェーズについて
  • 手札から選択したカードを使ってアーキテクチャを組む
    • 例)EC2とS3を組み合わせた場合・・・「EC2上でWebアプリを稼働させてそのログをS3に保存」など
  • 実際の現場で使われなさそうでも、各サービスの仕様に則っていればOK。逆にサービスで実現不可なものはNG。
ビルダーカードを出した場合の効果について
  • ビルダーカードには条件に合うカードと組み合わせることで、効果を発揮するものがある。以下は効果の一例。
    • 購入回数+1:通常、1回の手番で取得できるカードは1枚だが、ビルダーカードかWell-Architectedカードを追加で1枚取得(購入)できる。
    • 一枚引く  :プレイヤー山札から1枚引く。ビルダーカードを引いた場合、アーキテクチャに組み込んでもよい。

実際にやってみた感想

TCGゲーマー目線でのポイント

  • スターターカードは早めに捨てよう(山札の圧縮)
    • 本ゲームの勝ちにつながるのは、Well-Architectedカードの取得。
      取得にはビルダーカードを組み合わせる必要があるが、山札にスターターカードがあると手札にビルダーカードが揃う確率が下がる。
      そのため、スターターカードを早めに捨てることで、ビルダーカードを引く確率を上げる。
  • 汎用性の高いカードがやっぱりある。個人的にはEC2、StepFunctionとCloudFrontが強い。なんでも組み合わせられる。
    ただ、購入コストが高いのでゲーム準備の段階で確保しておきたい。

AWS初学者目線でのポイント

  • 汎用性の高いカードはAWSサービスの中でも使いやすいサービス(≒よく使われるサービス)なのでまずはそのサービスから覚えていく。
  • 他の人のアーキテクチャ説明を聞いて、わかるサービスを1つずつ増やしたり、使えそうなアーキテクチャ構成を増やしたりしていく。

より面白くするために(ネットコムローカルルール)

  • 自分の山札にビルダーカードが少ない序盤は単調になりがちなので一定の縛りを設けると、考える部分がより増えて盛り上がります。
    • アーキテクチャ構成の縛り
      • 必ず手札の全ビルダーカードを使ってアーキテクチャを組む/自分が前に組んだアーキテクチャは次の手番で利用不可/手札とは別に特定のビルダーカードを必ず使う などなど
    • 購入カードの縛り
      • 資格保有者は購入コストが常に+2される/同じカードを一人2枚までしか購入不可

最後に

仕事中にAWS資格保有者からの「ゲームしない?」の一言でたまたまやってみたのですが、なかなか面白かったです。
私自身、アーキテクチャを考えた経験も、AWSに関する知識もすっからかんでしたが、上級者がいると「あ~そういうやり方があるのね」と勉強になります。
このゲームでAWSのサービスへの興味を深めて、資格取得にチャレンジしてみるのはいかがでしょうか。

まぁ、このゲームをやるにあたっての最大の難関は、このゲームの入手(re:Inventへの参加)なのですが・・・。

ちなみに、この記事を書いている最中(2024年11月)に2ndエディションが出たようです。
aws.amazon.com

それでは、よいお年を。

VuePress × AWS で始めるモダンなブログサイト入門

はじめに

こんにちは、NRI ネットコムに新しくキャリアで入社しました永川です。普段はインフラエンジニアとして様々なシステムの開発・運用を担当しています。

今回は、VuePress と AWS を活用してブログサイトを構築する方法についてお話ししたいと思います。最近、VuePress を使ってシンプルでモダンなブログサイトを作成したので、その過程を題材に共有します。

VuePress とは

VuePress とはドキュメントやブログ向けの静的なウェブサイトを生成するオープンソースのフレームワークです。

Vue.js の生みの親である Evan You 氏により、コンテンツを主軸に置いた静的サイトの作成にフォーカスしたフレームワークとして開発されました。

いわゆる静的サイトジェネレーター (SSG) の一つで、ドキュメントやブログといった静的コンテンツに特化したツールとなっています。

動的コンテンツや更新の激しいコンテンツには向きませんが、静的な HTML ファイルをビルド時に事前に生成するので、デバイスやサーバーに負荷がかからず、ページの表示速度が非常に速いです。

また CDN (Contents Delivery Network) とも非常に相性がよく、スケーラビリティに優れているといった特徴があります。

SSG 関する詳しい説明はこちら↓ aws.amazon.com

主な機能

VuePress の主要な機能としては下記のものがあります。

  • Markdown から HTML を生成

  • 自動目次生成、全文検索、多言語に対応

  • Vue コンポーネントを埋め込み

  • 拡張性の高い様々なプラグイン

メリット

個人的に VuePress を使って嬉しいポイントは、

  • Markdown に対応している

  • VSCode などの使い慣れたツールを使ってドキュメントを記載可能

  • GitHub でドキュメントの管理をしたり、GitHub Actions を使用して CI/CD の仕組みを組みこむことが可能

のようなところだと思います。

普段開発で使用しているツールやプロセスをドキュメント作成にも適用できるところが非常に良いですね!

VuePress でブログを作る

今回作成したサイトでは VuePress のテーマの一つである VuePress Theme Hope を使用しました。VuePress 標準のテーマでも良いのですが、こういったテーマを使用することにより、さらに簡単に多機能なサイトを作成することができます。

実行環境

下記の手順は以下の実行環境で実施しています。

  • OS:MacOS Sonoma
    MacOS, LinuxOS で動作確認をしています。

  • Node.js:v18.17.1
    v18.0以上が必要です。VuePress の環境構築に使います。

  • npm:v9.6.7
    v.8.0以上が必要です。パッケージマネージャーとして使用します。

  • VuePress:v2.0.0-rc.9
    v2.0以上が必要です。ブログのフレームワークとして使用します。

ブログ構築の手順

ここからは VuePress を使ったブログサイトの構築方法を解説したいと思います。

まず、下記のコマンドでプロジェクトを作成します。

npm init vuepress-theme-hope@latest sample-blog

その後、表示されるプロンプトに従って、言語やパッケージマネージャーなどの設定を行います。

? Select a language to display / 选择显示语言 english (US)
? Choose package manager npm
? Which bundler do you want to use? vite
Generating package.json...
? Your project name sample-blog
? Your project version 2.0.0
? Your project description A project of vuepress-theme-hope
? Your project license MIT
Generating tsconfig.json...
? Does the project need multiple languages? No
? Do you need a GitHub workflow to deploy docs on GitHub pages? Yes
? What type of project do you want to create? blog
Generating Template...
? Initialize a git repository? Yes
Installing Deps...
This may take a few minutes, please be patient.
We can not correctly output progress bar from child process, so the process may look stuck.


Successful Generated!

プロジェクトの作成に成功したら、以下のコマンドで開発サーバーを起動してみましょう。

npm run docs:dev

実行すると、以下のような出力が表示されます。

> sample-blog@2.0.0 docs:dev
> vuepress-vite dev src

✔ Initializing and preparing data - done in 113ms

  vite v5.2.14 dev server running at:

  ➜  Local:   http://localhost:8080/
  ➜  Network: http://192.168.0.100:8080/
  ➜  Network: http://192.168.64.1:8080/

これで、初期設定済みのブログサイトが立ち上がりました!ブラウザで http://localhost:8080/ にアクセスをすると確認をすることができます。

ブログのカスタマイズ

一部省略をしてますが初期で作成される Vuepress Theme Hope のプロジェクトは下記のフォルダ構成になっています。

.
├── .github
│   └── workflows
│       └── deploy-docs.yml
├── package.json
└── src
    ├── .vuepress
    │   ├── config.ts
    │   ├── navbar.ts
    │   ├── public
    │   │   └── assets
    │   │       ├── icon
    │   │       └── images
    │   ├── sidebar.ts
    │   └── theme.ts
    ├── README.md
    └── posts
        ├── apple
        │   ├── 1.md
        │   ├── 2.md
        │   └── 3.md
        ├── cherry.md
        └── strawberry.md

このうち下記の4つほどを押さえていればブログサイトをカスタマイズして作り替えることができます。

  1. .src/.vuepress/config.ts, .src/.vuepress/theme.ts
    ブログ・著者の名前や説明、言語などのブログの基本設定を記載するファイル。
    ここでブログサイトのタイトルを変更したり、自身のプロフィールなどに書き換えたりすることができます。

  2. ./src/README.md
    トップページの md ファイル。
    ここでトップページに表示されるタイトルやコンテンツ、背景画像を変更することができます。

  3. ./src/posts/
    ブログ記事を管理するディレクトリ。
    このディレクトリ配下に md ファイルを追加していくことで記事を投稿することができます。
    (ナビゲーションバーやサイドバーも合わせて修正する必要がありますが、postsという名前を変えたり、同じ階層に別のカテゴリでmdファイルをまとめることも可能です。)

  4. .src/.vuepress/navbar.ts , .src/.vuepress/sidebar.ts
    上部に表示されるナビゲーションバーや、サイドバーの設定ファイル。
    ここでナビゲーションバーやサイドバーに表示される内容をカスタマイズすることができます。

    ぜひ色々いじって試してみてください!

AWS でブログをホスティングする

ここからは、ブログを AWS で公開する手順を解説します。

VuePress の公式サイトでは GitHub Pages や Heroku, Netlify などの静的コンテンツのホスティングサービスへデプロイする方法が紹介されていますが、今回は AWS と Github Actions で同じ仕組みを作成しました。

ホスティングサービスを利用しても良いのですが、コスト面やカスタマイズ性、学習目的を考慮して AWS を選択しました。

必要な準備

  • AWS CLI のインストール

  • GitHub リポジトリへ VuePress のプロジェクトをプッシュ

Amazon S3 とAmazon CloudFront の作成

AWS のアーキテクチャは Amazon S3 ( 以下 S3 ) で静的ファイルをホスティングし、Amazon CloudFront ( 以下 CloudFront ) で配信を行うシンプルかつ一般的な構成にしています。

また CloudFront 経由のアクセスのみを許可し、S3 への直接アクセスを防ぐため以下の設定を有効化しました。

  • S3 のブロックパブリックアクセスの有効化

  • CloudFront で Origin Access Control (OAC) を使用

  • OAC を利用し、CloudFront 経由のアクセスだけを許可する S3 バケットポリシーを実装

こちらの設定を活用すると、バケットの非公開や最小特権アクセスの実装といった S3 のセキュリティベストプラクティス に則りつつ、より安全にブログを公開できます。

AWS CloudFormation テンプレート

上記の S3 と CloudFront の作成・設定には AWS CloudFormation テンプレートを使用しました。

このテンプレートでは以下の4つのリソースを作成しています。

  • ブロックパブリックアクセスを有効化したS3 バケット

  • CloudFront からのみアクセスを許可するバケットポリシー

  • S3 へのセキュアなアクセスを実現する Origin Access Control (OAC)

  • S3 と連携する CloudFront ディストリビューション

AWSTemplateFormatVersion: 2010-09-09
Description: Template for S3 static site with CloudFront

Resources:
  S3StaticSiteBucket:
    Type: AWS::S3::Bucket
    Properties:
      PublicAccessBlockConfiguration:
        BlockPublicAcls: True
        BlockPublicPolicy: True
        IgnorePublicAcls: True
        RestrictPublicBuckets: True

  S3StaticSiteBucketPolicy:
    Type: AWS::S3::BucketPolicy
    DependsOn:
      - CloudFrontDistribution
    Properties:
      Bucket: !Ref S3StaticSiteBucket
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Sid: "AllowCloudFrontAccess"
            Effect: "Allow"
            Principal:
              Service: "cloudfront.amazonaws.com"
            Action: "s3:GetObject"
            Resource: !Sub "arn:${AWS::Partition}:s3:::${S3StaticSiteBucket}/*"
            Condition:
              StringEquals:
                AWS:SourceArn: !Sub "arn:${AWS::Partition}:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution}"

  OAC:
    Type: AWS::CloudFront::OriginAccessControl
    Properties:
      OriginAccessControlConfig:
        Description: Access Control
        Name: StaticSiteOAC
        OriginAccessControlOriginType: s3
        SigningBehavior: always
        SigningProtocol: sigv4

  CloudFrontDistribution:
    Type: AWS::CloudFront::Distribution
    DependsOn:
      - S3StaticSiteBucket
      - OAC
    Properties:
      DistributionConfig:
        DefaultCacheBehavior:
          AllowedMethods:
            - GET
            - HEAD
          CachedMethods:
            - GET
            - HEAD
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
          TargetOriginId: S3StaticSiteBucket
          ViewerProtocolPolicy: redirect-to-https
          Compress: true
        Enabled: true
        Origins:
          - DomainName: !GetAtt S3StaticSiteBucket.DomainName
            Id: S3StaticSiteBucket
            OriginAccessControlId: !GetAtt OAC.Id
            S3OriginConfig:
              OriginAccessIdentity: ""
        DefaultRootObject: index.html
        PriceClass: PriceClass_200
        ViewerCertificate:
          CloudFrontDefaultCertificate: true

静的ファイルのビルドとS3へのアップロード

S3 と CloudFront の作成が完了したら、VuePress のプロジェクトをビルドして、生成されたファイルを S3 バケットにアップロードします。

npm run build
aws s3 sync ./src/.vuepress/dist s3://<your-bucket-name> --delete

アップロードが完了後、作成したCloudFrontのURLにアクセスするとデプロイが成功していることを確認することができます!

※ 作成直後だと、バケットポリシーの反映に時間がかかるためか Access Denied のエラーが出ることがあります。その場合は時間をおいて再度アクセスしてみてください。

GitHub Actions で運用を自動化する

最後に GitHub Actions の設定を行い、main ブランチにマージされたら自動的に新しい記事が配信される仕組みを作成します。

VuePress Theme Hope でプロジェクトを作成した時点で .github/workflows 配下にデフォルトの YMAL ファイルが準備されているため、そこに AWS にデプロイするための下記の設定を追記します。

  • AWS のクレデンシャルの設定

  • S3 バケットへのコンテンツのアップロード処理

  • CloudFront のキャッシュ削除処理

使用した Github Actions の YAML ファイルは下記です。

name: Deploy Docs

on:
  push:
    branches:
      - main

env:
  BUCKET_NAME: "<your-bucket-name>"
  CF_DISTRIBUTION_ID: "<your-cloudfront-distridution-id>"
  AWS_REGION: "<your-region>"

permissions:
  id-token: write
  contents: read

jobs:
  deploy-gh-pages:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: npm

      - name: Install Deps
        run: npm ci

      - name: Build Docs
        env:
          NODE_OPTIONS: --max_old_space_size=8192
        run: npm run docs:build
        working-directory: ./src

      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v3
        with:
          role-to-assume: ${{ secrets.IAM_ROLE_ARN }}
          role-session-name: deploy-static-site
          aws-region: ${{ env.AWS_REGION }}

      - name: Deploy Docs
        run: |
          aws s3 sync --exact-timestamps --delete src/.vuepress/dist s3://${{ env.BUCKET_NAME }}/
          aws cloudfront create-invalidation --distribution-id ${{ env.CF_DISTRIBUTION_ID }} --paths "/*"
        working-directory: ./src

これで記事を作成し、その更新を mainブランチ へマージすることで自動的に公開される仕組みを作ることができました。

使い慣れたツールでブログ記事を執筆し、GitHubで管理しつつ自動で公開という一連の流れが完成したことになります!

まとめ

今回は VuePress を使ってブログサイトを作成し、AWS で公開する方法を紹介しました。

基盤を S3とCloudFrontで構築しましたが、これぐらいの小規模かつシンプルな静的サイトであれば、 CI/CD の環境の含めてまとめて作成してくれる AWS Amplify を使用してもよかったかもしれません。

また機会があれば次は Amplify を使って構築してみようと思います。

VuePress を使えばブログ以外でも簡単に静的サイトを作成することができるので、興味のある方はぜひこの記事を参考に作ってみてください!

参考URL

VuePress

AWS関連

GitHub Actions