はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Lambda でコンテナを使って動かすことができます。このときに、コールドスタートの時間がどれくらいになるか自信がなかったので、手元で簡単に試してみる記事です。コールドスタートの試行回数は数回程度なので、しっかりした検証ではない点を理解したうえで、この記事を活用ください。また、時期によってもパフォーマンスは変わってくると思うのでその点もご留意ください。 検証結果 個人的な意見ですが、コールドスタートでも、起動がかなり高速だと思いました。ざっくり以下の 2 パターンの検証です。 コンテナイメージサイズ : 以下の 2 種類 10

おすすめ! この Qiita の記事を進化させたものがあり、次の URL に書かれている手順がお勧めです。セキュリティを意識した WAF を利用した IP アドレス制限などが追加されています。 はじめに 2023 年 9 月に Amazon Bedrock が一般提供開始になりました。Amazon Bedrock は、API 経由で基盤モデルにアクセスできるマネージドサービスです。GitHub の generative-ai-use-cases-jp リポジトリで、チャット、RAG チャット、文章生成、要約、校正、翻訳、画像生成、といった利用方法をデモンストレーションできるアプリケーションが公開されています。 このアプリケーションは AWS CDK を使って簡単にデプロイができますが、AWS CDK に慣れていない方は若干の学習ハードルがあります。今回の記事で、AWS CDK に詳しくない

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Amazon Kendra は、様々なデータソースを横断的に検索できるエンタープライズ検索サービスです。Kendra から各種データソースに簡単に接続できるコネクタが提供されていて、Amazon S3, Microsoft SharePoint, Salesforce, ServiceNow, Google ドライブ, Confluence など連携できます。 今回の記事は、Kendra に WebCrawler というコネクタを使って、簡単に日本語の検索が出来る点を確認していきます。初めて Kendra を触ってみる点での備

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Amazon Linux 2023 が、2023 年 3 月 15 日に一般公開になりました。AWS に最適化されたパフォーマンスを提供する Linux ベースの 最新 OS です。OS を起動したままカーネルのパッチを適用できる kpatch の利用など、便利な機能が追加されています。 AWS Document に Amazon Linux のリリース頻度やサポート期限が記載されているのも大きい変更点です。2 年ごとにメジャーバージョンがリリースされ、5 年の長期サポートが提供されます。 引用 : https://docs.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? キャパシティ編もよかったらどうぞ https://qiita.com/sugimount-a/items/6df950c0abc02c5bcb6c はじめに Amazon ECS と AWS Fargate を使ってサービスを提供しているときに、コストを最適化する方法があります。一例として、次のコスト最適化の方法を挙げます。 Fargate Spot : 空きキャパシティを利用 Savings Plans : 1年 or 3年の期間契約 上記の2個は Fargate の購入方法が異なります。Fargate Spot は通常の価格と比べて

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに AWS Network Firewall では、ネットワークトラフィックをきめ細かく制御するファイアウォールルールを定義できます。AWS のウェブサイトでは以下のユースケースが紹介されています。 VPC 間のトラフィックを検査 アウトバウンドトラフィックをフィルタリング インバウンドのインターネットトラフィックの侵入を防ぐ AWS Direct Connect と VPN のトラフィックを保護する アウトバウンドトラフィックの HTTP/HTTPS 通信を、特定のドメインのみ許可して、他のドメインを禁止ができます。事前に確認し

はじめに 前回の記事では、セルフサービスな MFA 環境を作るための IAM Policy の方法を学びました。今回は、AWS CLI から MFA を利用するときの方法を整理したいと思います。 まず、前提知識として整理すると、AWS のマネージメントコンソールで MFA を有効化する設定項目があります。 これを有効化すると、マネージメントコンソールにログインするときに、MFA 認証が求められます。 この機能を有効化しただけでは、この IAM User に紐づくアクセスキーをつかった AWS CLI の実行には何も影響しません。表現を変えると、アクセスキーを払い出したら、MFA 関係なくいろいろな API が実行できるわけですね。 これだと困るので、IAM Policy で MFA が無いときにアクセスを禁止するルールを設定すると、AWS CLI でも MFA が有効になります。すごいシン

はじめに AWS App Runner は、AWS 上でコンテナ化されたアプリケーションを簡単に構築・運用できるフルマネージドサービスです。オーケストレーションワークフローや CI/CD の整備を App Runner に任せて、利用者はアプリケーション開発に集中することができます。 App Runner は、「サービス」という概念で、アプリケーションの作成や管理を行います。「サービス」は、2 種類の作成方法があります。 Code-based service Image-based service 1 つ目の Code-based service は、App Runner 側で用意されたランタイムを利用してアプリケーションを動かします。ユーザー側ではアプリケーションのソースコードを GitHub Repository に用意するだけで、あとは App Runner 側で自動的に環境作成やデ

FireLens でログ出力を分岐する記事もよかったら見てみてください。 https://qiita.com/sugimount-a/items/c43b1bd4f9ecbbb448b7 Amazon ECS におけるログ出力 Amazon ECS 上で稼働するログを、外部に保存する方法は、主に 3 つあります。 引用 : https://speakerdeck.com/prog893/aws-startup-tech-meetup-number-3-kantankontenaroginguxuan-shou-quan awslogs logging driver 独自で Fluentd のサイドカーを構成 FireLens awslogs logging driver は、シンプルに実装できますが、ログの出力先は CloudWatch Logs だけです。大量なログが発生する環境では、C

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Redshift Serverless が 7/13 に GA されました。従来の Redshift (provisioned cluster) では、クラスターを構成するインフラを意識しながらデプロイする方式でした。Redshift Serverless ではインフラ管理が不要となり、より簡単に、より運用負担を軽減してご利用いただけます。データを準備して Redshift Serverless に取り込むだけで分析ができ、料金は使用した分だけ発生します。これにより、利用頻度が少ない分析処理や夜間のみ実行されるワークロードなど

Create rule を押します。 作成したあとは inactive 状態なので、Set as active を押します Set as active を押します。 メールを SES に送信 ここまでの設定で、送信したメールが無事に S3 に保存されるか確認します。Gmail で適当にメールを送信します。 S3 上にファイルが保存されています。この中にメール本文や添付ファイルが含まれています。 Lambda 関数作成 S3 に保存されるメールデータの中から、メールの本文と添付ファイルを抜き出す処理を行います。S3 にメールデータが置かれたことをイベント通知で検知して、Lambda 関数を起動します。次の Python コードで、Lambda 関数を適当に作成します。 行っている内容は、ざっくり以下の通りです。 S3 イベント通知をトリガーに Lambda 関数を起動する Lambda 関数

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 前回の記事では、Fargate Spot の中断について、考慮すべきポイントを整理しました。今回の記事では、キャパシティについて考えていきたいと思います。 Fargate Spot は AWS の空きキャパシティを利用することで、通常より最大 70% OFF の価格で利用できます。一方、空きキャパシティが確保できなくなった場合、いつでも中断される可能性があります。中断される際には、AWS から 2 分前に通知として SIGTERM を受け取ることが出来るため、アプリケーションを安全にシャットダウンできます。 中断については、2

はじめに Amazon S3 を使っている中で、他の AWS アカウント上にある S3 バケットのデータを利用したくなるときがあります。この時は、主に以下の3つの方法が利用可能です。 S3 バケットのクロスアカウントレプリケーション バケットポリシー スイッチロール 今回は、「S3 バケットのクロスアカウントレプリケーション」について、設定手順の確認をしていきます。 前回の記事では、「S3 バケットのクロスアカウントレプリケーション」を取り上げました。今回の記事は「バケットポリシー」と「スイッチロール」の方法を確認していきましょう。 バケットポリシー 構成図 構成図はこんな感じです。S3 Bucket の共有元でバケットポリシーを設定し、共有先のユーザーに紐づく IAM Policy でアクセス許可を行う形です。 アカウント1 : S3 Bucket の作成 クロスアカウントアクセス用の

はじめに Amazon ECS は、コンテナを動かしうまく管理するためのコンテナオーケストレーションサービスです。新たなバージョンのコンテナをデプロイするときに、いろいろなデプロイの方法が取れますが、ECS 側で用意されているデプロイ戦略が3種類あります Rolling Update : Service の中で稼働しているタスクを少しずつ順繰りアップデートする方式 Blue/Green Deployment : 新たな環境である Green 環境を用意して、LB レイヤーで切り替える方式 External Deployment : 外部のサードパーティの何かでデプロイをコントロールする方式 こちらの Document に記載があります。 : https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-types.htm

はじめに AWS Lambda が良く語られますが、予測不可能なリクエストが来た時に、多くのインスタンスを横に並べてリクエストを捌く構成があります。AWS Lambda の場合は、1リクエスト1インスタンスとなるので、需要が高まったときには必然的に多くのインスタンスが立ち上がる構成になります。この時、インスタンス が RDS のコネクションを取得している場合、多くのデータベースコネクションを取得することにより、データベース側の負荷が高まってしまう課題がありました。 こういった問題を解決するための選択肢の一つとして、RDS Proxy と呼ばれるデータベースのコネクションをプールしてくれる機能があります。Amazon RDS に備わっている機能となっており、複数のインスタンス間でデータベースコネクションをプールしてくれます。 RDS Proxy を利用するメリットは次の通りです。 アプリケー

はじめに Amazon Simple Storage Service (Amazon S3) は、高いスケーラビリティ・可用性・パフォーマンスなどを提供するオブジェクトストレージサービスです。Web サービスで画像データをアップロードしたいときに、S3 の署名付きURL を活用することが出来ます。 画像データをアップロードする際に、アプリケーションサーバーなどのバックエンドサーバーを経由する方法がありますが、CPU やネットワーク、メモリなどのリソース消費が気になります。アップロードの頻度が多く容量が大きいファイルだと、パフォーマンスへの影響が無視できません。そこで、ブラウザから直接 S3 にアップロードする方法を採用できます。 一方、セキュリティの観点で、S3 Bucket は Private にしておきたいです。Private のまま一時的にアップロードのための URL を生成する機能

はじめに DNS の CNAME レコードは、他のレコードと同じ値を使った共存が出来ません。RFC で定義されている、DNS の中のルールになっています。 A CNAME record is not allowed to coexist with any other data. TXT レコードやAレコードなど、種類問わずすべてのレコードと共存することが出来ません。 ELB を使って Web サービスをインターネットに公開する際に、CNAME レコードを使って公開する方法がありますが、上記の制限が問題になる場合があります。具体例を挙げましょう orenoservice.co.jp という名前でとあるWebサービスを公開している この名前は CNAME レコードとして、ELB を指している なんらかの事情で、orenoservice.co.jp の値を使って TXT レコードを作りたい (G

はじめに AWS マネージメントコンソールに、Identity Provider を使った SSO ログインがやりたいときがあります。AWS Organizations が使える環境だったら、AWS SSO を使えば比較的楽に実現できます。しかし、Organizations が使えない環境でも、AWS IAM で Identity Provider の設定をすることで、SSO が実現できます。 今回は、AWS IAM と Azure AD 間で、SAML を使ったフェデレーションを行っていきます。 わかったこと 今回の検証を通じて、わかったことを最初に書きます。 この記事の構成では、Azure AD 側でプロビジョニングの設定を加えても、AWS IAM User などには自動的に追加されない https://docs.microsoft.com/ja-jp/azure/active-dir

はじめに Kubernetes では、コンテナ(Pod) を外部からアクセスさせるために、Service LoadBalancer を使って外部公開が出来ます。LoadBalancer を作ったときに、どういうことが Kubernetes クラスタ上で起こり、どのように通信出来るのでしょうか。 マネージドサービスを使っていでも、何かの拍子に通信障害が発生することがあります。障害を解析するためには、正しい通信経路を把握することが重要です。 通信経路を調査した内容を備忘録として残します。Kubernetes 環境は、Oracle Cloud のマネージドサービスである OKE を使って調査していますが、他の環境でも基本的には同じような挙動になると思います。 事前準備 OKE クラスタを作成して、Deployment と LoadBalancer を作成します。作業用ディレクトリを作成します。

Visual Studio Code に 超絶便利な Oracle DB 拡張機能 (Oracle Developer Tools for VS Code) を入れて、ATPに接続するoracleVisualStudioCodeoci はじめに Microsoftが提供している、ほぼすべての言語に対応しているコードエディターのVisual Studio Code があります。 様々な便利機能があり、とても快適にプログラミングが出来るのですが、拡張機能で Oracle DB との連携が出来ます。 SQL の補完が便利すぎるので、ぜひみなさん使ってみましょう！ 手順を書いていきます。 Visual Studio Code Install 以下のURLから適当にインストールします https://azure.microsoft.com/ja-jp/products/visual-studio-c

初めに Kubernetes には、Kubeadmをはじめとした半自動インストーラーがあり、比較的簡単にインストールを行うことが出来ます。 このままでもKubernetesクラスタを利用することはできますが、本番運用を考えると、Networkの疎通経路を正しく理解する必要があります。 私のローカル環境のKubernetesで検証・確認した内容をいかに共有します。 皆様のお役に立てましたら幸いです。 Pod同士の通信 (同一マシン) Pod同士の通信 (異なるマシン) Service(ClusterIP) を経由した通信 Service(NodePort) を経由した通信 Kubernetesなどのバージョン情報を以下に記載します - Kubernetes 1.10 - Kubeadm 1.10 - CentOS 7.5 Podの準備 nginx Pod を 4個作成します 以下のマニフェス

はじめに Persistent Volume とは、Kubernetes の Pod でストレージを管理・使用するためのものです。 Persistent Volume を、Deployment・StatefulSet で使用したときに、どのようにPodへ紐づけられるかが不明だったため、検証を通じて理解を深めていきます。 Master1台・Node2台のKubernetesクラスタに対して、NFSを使用してPersistent Volume の検証をします。 NFSサーバの準備 適当にNFSサーバを準備する 以下のURLを参照 NFS Clientの準備 Node が NFSマウントを実施するため、Nodeに NFS Client の事前準備を行う 念のため、Master と Node全台 で install をしておく 以下のURLを参照 Persistent VolumeとDeploym

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに Kubernetesのエコシステムの中に、CDツールの役割としてSpinnakerが存在しています。今回は、On-Prem環境のKubernetesクラスタ環境で、SpinnakerとKayentaを利用したCanaryリリースの手法を確認します。 環境情報 Kubernetesクラスタ : 1.11.3 (kubeadmで構築済) Halyard導入マシン : Ubuntu16.04 Halyardバージョン : 1.10.1-20180912131447 Spinnakerバージョン : 1.9.4 前提作業 Halyard Install用マシンを準備 Spinnakerには、InstallerツールのHalyardというものが存在しています。Spinnakerの全機能を使用するために、Halyardが必要です。Halyardを導入するUbuntu16.04を適当に準備しま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 CentOS7.1を使用して、内部向けDNSを構築します。 DNSサーバーとして、BIND 9.9.4を使用します。 各種サイトや構築を通じて、自分なりの理解した内容などを記載していきます。 以下URLを参考にしました。 http://centossrv.com/bind.shtml http://www.itmedia.co.jp/keywords/bind_tsukuru_dns_server.html http://www.atmarkit.co.jp/ait/articles/0309/09/news001.html http://www.atmarkit.co.jp/ait/articles/0310/15/news001.html http://qiita.com/shrkw/items/8410e9cb65eb789a40e1 DNS構築 DNSインストールディレクトリ