2021/03/20 (Sat.) JAWS DAYS 2021 トラックB 10:40〜
2021/03/20 (Sat.) JAWS DAYS 2021 トラックB 10:40〜
第1回目は「非エンジニアがAWSソリューションアーキテクトに合格するまで(1)」をご覧ください。 第2回目は「非エンジニアがAWSソリューションアーキテクトに合格するまで(2)」をご覧ください。 実際に実行したやり方と参考文献 自分はこれまでと方向性を切り換え、ようやく『BlackBelt(ブラックベルト)』に目を向けました。 『BlackBelt(ブラックベルト)』とは、Amazonのオンラインセミナー。 https://aws.amazon.com/jp/aws-jp-introduction/ ブラウザ上でのスライドとPDF、オンデマンドのセミナー(口頭で説明)があります。ひとつあたりだいたい1時間程度。 特に以下のサービスについて、重点的に復習しました。 EC2、VPC、EBS、S3(Glacier)、RDS、DynamoDB、ELB、AutoScaling、CloudWatch、
AWS学習を始めようと考えている人 「AWSとは、概要や全体像、メリットデメリットが知りたい」 「AWSの学習方法が知りたい」 こういった疑問に答えます。 本記事のテーマ 【AWS初心者向け】AWS学習方法まとめ【15時間で達成できる】 AWS学習の始め方 AWSやクラウド初心者の方がAWSを学ぶための方法を纏めました。 ①クラウドを学ぶ ②AWSの概要を学ぶ ③知識の定着(AWS公式ハンズオン実施) ④AWS運用の現場に参画 知識定着のため、インプット、アウトプットのバランスを考えてまとめています。 IT基礎知識(基本情報技術者レベル)がある前提になっていますので、 インフラ基礎知識が足りていないと感じる方には下記の記事もおすすめです。 記事の信頼性 筆者はAWS経験5年程度です。AWS資格は5冠達成しました。 現在は大規模ECサイトのAWS運用を任されるようになっています。 今回紹介し
AWS Lambdaの環境がどのようになっているか、ユーザが用意したLambdaファンクションがどんな感じで実行されるかってあたりを可能な限り詳しく説明したいと思います。 はじめに 大前提 コールドスタート/ウォームスタート コントロールプレーン/データプレーン アイソレーション AWS Lambdaのコンポーネント群 同期実行かつ初回呼び出し(コールドスタート)、もしくはスケーリング 同期実行かつ再利用(ウォームスタート) 非同期実行 スケールアップ エラーハンドリング リトライ その他 ネットワーク まとめ はじめに この投稿は2020年9月29日の21時から開催予定のイベント(ライブストリーミング)で話す内容です。 serverless-newworld.connpass.com もし間に合えば、かつ時間があればぜひライブ配信のほうにも参加ください。 (2020.09.30 upda
サーバーレスでサーバーサイドレンダリング(SSR)の後編です。前編はこちら。 www.keisuke69.net なお、同内容をこちらのイベントでも話す予定ですので興味あるかたはぜひこちらも。 serverless-newworld.connpass.com はじめに サンプルアプリ serverless.yaml 最後に はじめに 前回、SSRとはって話を簡単にしました。今回はSSRをAWSのサーバーレス、つまりAWS Lambdaでやってみたいと思います。 今回はVue.jsのフレームワークであるNuxt.jsで作ったサンプルアプリのSSRをLambdaで試してみます。 前回のブログでNuxt.jsでの例という説明をしましたが、今回はそこを実際にやっていく感じです。 なお、Nuxt.jsをLambdaで動かす場合の話って実はググってもあまり出てきません。いくつかの記事が出てくるだけです
こんにちは。SRE の @chaspy です。 Quipper では AWS 上で Kubernetes Cluster を運用してサービスを提供しています。 これまで kube-aws を用いて Kubernetes Cluster を Self Host してきましたが、このたび Managed Services である Amazon EKS に移行しました。(以下、 Amazon EKS を EKS と表記します) 本記事では、 Kubernetes Cluster の移行で遭遇した問題をどのように解決したかを説明します。また、数多くの Application が稼働している Platform を移行する際にどのような点を考慮するとよいのか、経験を通して学んだことを共有します。 EKS への移行を検討している方はもちろん、Platform Migration に携わる方にとって学びに
真野 智之 (Tomoyuki Mano) <tomoyukimano@gmail.com> version 1.0, 2020-06-19
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
ども、大瀧です。 VPCのプライベート接続でオンプレミスのIPv6網と接続する機会があり、IPv4で上手く使う手がないかと試行錯誤した結果をメモとして残しておきます。 前提となる構成 拠点ネットワークとAmazon VPCはIPv4、経由するIPv6網内がIPv6という構成です。拠点側ルーターとAWS側ルーター *1間でv4v6変換をするのがシンプルですが、今回はAWS側ルーターに制約があり、AWS側ルーターとGatewayインスタンス(EC2)間でISATAPトンネルを張り、GatewayインスタンスにIPv6アドレスを割り当てています。下図のイメージです。 そこで今回は、拠点側ルーターとGatewayインスタンスのIPv6アドレス同士でIPv4 over IPv6となるIPIPトンネルを張ることにしました。 検証は以下の環境で行いました。 拠点側ルーター : YAMAHA RTX810
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
zomです。 この記事はLIFULL Advent Calendar その3の23日目の記事です。つまり私の誕生日です。 要件が非常に軽いもので、アプリケーションサーバを導入することですらオーバースペックなことも世の中にはあると思います。 最近ではそういった場合はLambdaでさっくり作ったりするのが最近のトレンドかと思います。 が、しかし私はJSに対して苦手意識があり、早くRubyが実行できるようになったらいいのに…なんて想いからLambdaを敬遠して生きてきました。(JavaやPythonは書けないです。。。) (2018年のre:inventでRubyが実行できるようになったのがすごく嬉しいです。ちょっと早いAWSサンタさんありがとう) といった事情からnginx*mrubyでアプリケーションサーバなしにRubyを実行する環境を作るに至りました。 あと、もともとRubyKaigi20
0. はじめに Amazon CloudWatch Logs サービスを理解、活用するために、Amazon CloudWatch Logs ユーザーガイド を一読して、個人用に概要と最低限設定しておくべきことをまとめる。 補足は、Amazon CloudWatch の よくある質問 の よくある質問を参考にしている。 0.1 概要、注意点など (1) CloudWatch Logs 特徴 (2) IAMポリシー、IAMロール IAMロールの注意点 (3) CloudWatch Logs エージェント CloudWatch Logs エージェントは、Amazon Linux または Ubuntu を実行する Amazon EC2 インスタンスでログデータを CloudWatch Logs に自動送信する方法を提供する。 前提条件 リファレンス サポートしているログローテート エージェントを停
Elastic Beanstalk は2016年12月にアップデートされたプラットフォームから、CloudWatch Logs との連携が強化され、コンソールからオプションを有効にするだけで、簡単にログが Stream に出力できるようになりました。 ただ、例えば Tomcat 環境であれば現時点では以下のログが対象になり、catalina.out が含まれません。 /var/log/eb-activity.log /var/log/httpd/error_log /var/log/httpd/access_log /var/log/nginx/error_log /var/log/nginx/access_logということで、catalina.out を CloudWatch Logs に出力するために、以下のファイルを .ebextensions に含める必要があります。 cwl-ca
AWS Summit2017で聞いてきたサーバレスアプリのアンチパターンとチューニングのメモです。 Lambdaの仕組みの中まで知らなかったのと、気をつけるべきところが多くあったので、とても参考にさせていただいております。 プラスで自分が他に参考にしたサイトもリンクさせていただきます。 アプリが遅くなる原因 ① プログラムの問題 ロジックそのものの問題は、各言語のベストプラクティス、最適化手法はそのまま当てはめるべき Node.jsで自分は書くことが多いので、下記を参考にしている Node.jsベストプラクティス ② コンピューティングリソース不足 メモリ設定は最適にすること メモリサイズと比例してCPU処理能力も割り当てられる コストを気にしがちだが、メモリを増やせば処理時間は早くなるので、結果的にコストはそこまで変わらないときもある ※ ちょっとずつ変更して性能が変わらないところが最適
ご機嫌いかがでしょうか、豊崎です。 ELB(Elastic Load Balancing)はその名の通りロードバランサーなので、負荷分散のイメージが強いと思いますが、 ここではWEBサーバが1台でも前段にELBを置いた方がいい理由についてまとめたいと思います。 WEBサーバが1台でもELBを置いた方が良い理由 インスタンスの差し替えが容易 運用が開始した後、EC2に対して修正を行う必要がでた場合、インスタンスの差し替えが容易になります。 DNSの変更を行うことなく、バックエンドの切り替えが可能です。 ELBのヘルスチェックで監視 ELBのヘルスチェックを利用してWEBサーバの死活監視を行うことができます。 CloudWatchアラームを組み合わせて通知が可能です。 HTTPSのSSL終端をELBへ SSLを利用する場合、EC2でSSLを終端させるとOpenSSLなどの管理が発生します。 一
これに評価が許可になる条件Bを組み合わせると、 (NOT A) or B → デフォルト拒否 or 許可 → 許可 A or B → 明示的拒否 or 許可 → 拒否 となり、評価がデフォルト拒否になっているからといって、拒否設定した気になっていると、 他のポリシーとの組み合わせでうっかり許可になってしまう場合がある。 対象リソースの指定 バケットポリシーやIAMポリシーで、ある Action を許可/拒否する場合、対象 Resource を ARN で指定する。 バケットに対する Action は Resource としてバケットの ARN(arn:aws:s3:::bucket) を指定する。 オブジェクトに対する Action は Resource としてオブジェクトの ARN(arn:aws:s3:::bucket/*) を指定する。 AWS Management Console
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く