タグ

AWSに関するasflash8のブックマーク (10)

  • Aurora MySQLをMySQL8.0へ移行した話 - inSmartBank

    こんにちは!SREを担当してます上平と申します。 このエントリーではAurora MySQL5.7互換からMySQL8.0互換への移行を実施した際の流れや学びに関して紹介したいと思います! B/43 では Aurora MySQL5.7系をサービスリリースから使っており、Aurora MySQL バージョン2のサポート終了日(2024/10/31)が近づいているのもあったので、移行することにしました。 Amazon Aurora バージョン - Amazon Aurora これからAurora MySQL8.0へ移行を検討されている方の参考になれば幸いです。 想定される読者 Aurora MySQL 5.7系を使っていて、アップグレードを検討している方 実際の Aurora MySQL 8.0 への移行手順を知りたい方 AWS インフラに興味がある方 前提 Aurora MySQL5.7互

    Aurora MySQLをMySQL8.0へ移行した話 - inSmartBank
    asflash8
    asflash8 2023/07/04
    知見だ。ありがてえ
  • Lambda Web Adapter でウェブアプリを (ほぼ) そのままサーバーレス化する Lambda Web Adapter - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

    開発者の皆さまこんにちは!AWS Japan で Prototyping Engineer として働いている友岡です。 今日は AWS Lambda Web Adapter というソリューションをご紹介します。VM やコンテナ用に実装されたウェブアプリを、ほとんどそのまま Lambda でも動かせるようにするツールです。(なお、ここで言うウェブアプリとは HTTP を話す任意のウェブサーバーアプリを指します。) Lambda を初めて触る方がまず戸惑うのが、実行方法が Lambda 特有のものになることではないでしょうか。以下は TypeScript の例ですが、Lambda アプリケーションは基的にこのようなインターフェースの関数 (ハンドラー) を実行する形になり、また外部からの入力はハンドラーの第 1 引数 event として渡されます。

    Lambda Web Adapter でウェブアプリを (ほぼ) そのままサーバーレス化する Lambda Web Adapter - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
  • Amazon Aurora MySQLのS3 Export機能がBigQueryの外部テーブルとフィットした話 - TVer Tech Blog

    はじめまして。山根と申します。データ基盤の運用保守をしています。 今回は TVerメンバーによるアドベントカレンダーの8日目の記事になります。 タイトル通り、Amazon Aurora MySQLのデータを BigQueryに転送している話を紹介したいと思います。 背景 弊社では、TVerで公開するコンテンツをAurora MySQL(AWS)上で管理しています。 一方で、視聴データなどのデータ分析基盤は BigQuery(GCP)上に構築されており、 コンテンツのメタデータを利用するためにはMySQLのデータをBigQueryに取り込む必要があります。 今回は分析用途のため、1日に数回MySQL snapshotをとり、BigQueryに転送するシステムを構築しています。 考慮事項 考慮事項は以下の通りです。 運用コストを低くかつ不要な情報は取り込まないことを意識しました。 できるだけ分

    Amazon Aurora MySQLのS3 Export機能がBigQueryの外部テーブルとフィットした話 - TVer Tech Blog
  • Lambda@Edgeを使ってPOSTリクエストボディを取得してみる | WafCharm(ワフチャーム)|AIによるAWS WAFのルール自動運用サービス

    【概要】 AWS WAFには、サンプルログ・フルログというログ機能がありますが、どちらの機能もPOSTリクエストボディは出力されません。 そこで、今回はLambda@Edgeを使用して、CloudFront経由のPOSTリクエストボディを取得する方法を紹介します。 以下のViewer requestのタイミングでLambda@Edgeを実行させて、POSTリクエストボディを取得します。 Vierwer requestのタイミングで実行させる理由は、誤検知調査において、取得したPOSTリクエストボディとフルログを紐付けしながら調査することになるのですが、その紐付けをするための共通キーとして”requestId”が含まれるためです。 【CloudFront】 CloudFront とはグローバルに広がるコンテンツ配信ネットワークです。世界各地にあるサーバにキャッシュを保存することで、様々な国か

    Lambda@Edgeを使ってPOSTリクエストボディを取得してみる | WafCharm(ワフチャーム)|AIによるAWS WAFのルール自動運用サービス
  • セキュアなTerraformの使い方 ~ 機密情報をコードに含めず環境構築するにはどうしたらいいの?

    22/8/5 CloudNative Security Conference 2022にて発表

    セキュアなTerraformの使い方 ~ 機密情報をコードに含めず環境構築するにはどうしたらいいの?
    asflash8
    asflash8 2022/08/08
    なるほどー。一旦ダミーで作成してあとから差し替える+ignore changesにするのか。ただAPIキーはどうすれば・・・
  • コードで学ぶAWS入門

    各方面でご好評をいただいている講義資料ですが,この度増補・改訂のうえ書籍として出版することが決定いたしました! 書籍限定の書き下ろしの3章 (約100ページ分!)を新たに追加して,2021年9月27日に発売予定です. この資料を気に入っていただいた方は,手に取っていただけるとありがたいです. ここで公開している資料は引き続きオンラインで無料で読めますので,ご安心ください🙇

  • AWS導入前に知っておきたかった「AWSアカウント設計」 - Qiita

    1.はじめに みなさんAWSのアカウント設計はどのようにしていますか? AWSを使ってシステムをセキュアに開発・運用していくためには、 AWSアカウント(*)の設計が重要になりますよね。 AWSアカウント1つのみで運用されてる方は、誤操作や、 誰にどの権限を与えるかのポリシー設計等で困る方もいらっしゃるのではないでしょうか。 (私もその一人です。) 内容は、『Amazon Web Services 業務システム設計・移行ガイド』にも載っているので、 悩んでる場合は、購入をおすすめします!(こちらの書籍と実体験を元に書いてます。) 今回はAWSアカウント設計について、パターン別にメリット・デメリットを書いていこうと思います! (*)AWSアカウントとは、AWSを使用するためのマスターアカウントのことを指しています。 ※IAMユーザーとは別物です! 2.AWSアカウント設計パターン紹介

    AWS導入前に知っておきたかった「AWSアカウント設計」 - Qiita
  • 15分で教えるAWSの複数アカウント管理 - Qiita

    AWSアカウントの分け方や複数アカウントの管理方法を教える機会があったので書いた記事です。 管理上もっとやることが多いと思いますが、目立ったところを教えるために書いています。 なぜアカウントを分ける必要があるのか 参考:AWS におけるマルチアカウント管理の手法とベストプラクティス 上記スライドにすべて書いてありますが個人的な意見も交えてると、アカウントを分ける基準は コスト と 環境 と 役割 の3つ。 コスト アカウント単位で分ければタグによるコスト配分をしなくてよくなる プロダクト単位や環境単位で正確なAWS費用を出せる 環境 オペミスを防ぐためにも番と開発ではアカウントを分けたほうがいい 分けていると開発やテスト時は多少雑な IAM 管理でも許される 役割 コスト配分先が同じでも、利用者が異なっていてシステム上分けることが可能ならアカウントを分けたほうが IAM の権限管理が複雑

    15分で教えるAWSの複数アカウント管理 - Qiita
    asflash8
    asflash8 2020/10/19
  • 【Part2】AWS Greengrassの特徴と環境構築|imaimai

    AWSでエッジコンピューティング環境を作る、Part2.です。実際に作っていきましょう ※ 下記記事を読んでおくと、わかりやすいと思います。 ☑ AWS IoT入門(Raspi接続編) ☑ サーバーレスアーキテクチャの要「Lambda」とはなにか AWS IoT Greengrassとは?めちゃくちゃざっくりいうとこんな感じ AWS IoTの拡張的機能 エッジ端末への遠隔デプロイを可能にする エッジ側にLambdaの機能をもたせられるAWS IoT Coreを用いると、AWS側がメッセージブローカとして、ラズパイなどの端末デバイスと、AWSの他サービスを繋げるようになりました。これにより、データの可視化や分析をクラウド上で行えるようになったわけです。 しかし、この場合、AWS IoTにデータを送る部分は、端末デバイスの中でアクセスして書かなければいけませんでした。内部の処理を変えるために、

    【Part2】AWS Greengrassの特徴と環境構築|imaimai
  • キャッシングの課題と戦略

    Amazon で長年にわたってサービスを構築してきた中で、新しいサービスを構築するけれども、このサービスはそのリクエストを満たすためにいくつかのネットワーク呼び出しを行う必要があるというシナリオのさまざまなバージョンを経験してきました。おそらく、この呼び出しは、リレーショナルデータベース、Amazon DynamoDB などの AWS のサービス、または別の内部サービスに対するものです。単純なテストまたは低リクエストレートでは、サービスはうまく機能しますが、問題もあることにも気付きました。問題は、この他のサービスへの呼び出しが遅いこと、または呼び出し量が増えるとデータベースのスケールアウトに費用がかかることです。また、多くのリクエストが同じダウンストリームリソースまたは同じクエリ結果を使用していることに気づいたため、このデータをキャッシュすることが問題の解決策になると考えています。キャッシ

    キャッシングの課題と戦略
  • 1