2018/10/5 に開催された Analytics Architecture Night - Tokyo の発表資料です https://analyticsarchitecturenighttoky.splashthat.com/ Read less
![Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート](https://cdn-ak-scissors.b.st-hatena.com/image/square/828cc66caffae2323b3eca7a939aea50fe1d7aeb/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fanalyticsarchitecturenight-tokyo201810-redshift-181005125035-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
西澤です。クラスメソッドに入社してからおよそ5年間クラウドの推進やAWS技術に関する支援をさせていただいております。この経験を何か形にしたいと思い、少し遅れてしまったのですが、Developers.IOイベントに乗じてまとめさせていただきました。 発表資料 資料はこちらにアップロードしております。 夜間に録音したので覇気が無い感じになってしまいましたが、動画はこちらです。 まとめ 「AWS設計でやりがちな失敗パターン」というタイトルで考え始めたのですが、もっともお伝えしたい点は、AWSを利用されるお客さまのマインドセットを変え、クラウドを活用できる組織に変わって欲しい、というところに集約できるかなと思います。技術的な問題以上に、考え方を変えられないこと、組織を変えられないことが、クラウド活用を阻害するアンチパターンになっていると思いました。 どこかの誰かのお役に経てば嬉しいです。
技術一課の杉村です。AWS Client VPN が東京リージョンにやってきました。 AWS Client VPN がアジアパシフィック (ムンバイ) と アジアパシフィック (東京) の 各AWS リージョンで利用可能に 特にエンタープライズのお客様にとっては、社内のシステムとリモートにいるクライアントPCを繋ぐいわゆるクライアントVPNはなじみ深いものです。 「ふむ、AWS Client VPNが東京リージョンに来たのか。検証しとくか!」と思いたちいざ触ってみると、初見では結構わかりづらい部分がありました。一度理解してしまえば簡単にクライアントVPNを実現できますので、AWS Client VPNの概念、そして実際の設定手順を解説してみたいと思います。 1. ざっくりポイント AWS Client VPN のポイントを記載します。 VPC上に Client VPN Endpoint を
SREチームの @tmknom です。ジョジョ5部のアニメ化に興奮を隠せない今日このごろです。 みなさん、AWS Organizationsは使ってますか? クラウドワークスでも最近使い始めました。AWS Organizations、超絶便利です。こんなに便利なのに、意外と公開されてる事例が少なくて、ぐぬぬってなります。というわけで、使い始めたばかりですが、サクッと公開してみます。他の会社さんも、公開してくれ!! AWS Organizations マルチアカウント戦略 先行事例の調査 コンセプト策定 Terraform戦略 Terraformモジュールによる共通化 インフラテンプレート VPCのIPアドレス空間 メールアドレスの管理ポリシー OU(Organizational Unit)の責務 管理用AWSアカウントの責務 Masterアカウントによるアカウント管理 組織 OU(Orga
こんにちは、虎塚です。 先日のCM re:Growth Developers.IO Meetup 11 Tokyo で「10分でわかるKey Management Serviceの仕組み」という発表をしました。今日は、イベントに参加されなかった方がご覧になっても内容が伝わるように、発表内容を記事に起こしてみました。 はじめに Key Management Service(KMS)は、先月開催されたre:Invent 2014で発表された新サービスです。すでに全リージョンで利用できます。このサービスを使うと、データの暗号化/復号用の鍵をAWS上で管理できます。 ところで、KMSのAPIドキュメントを流し読みすると、マスターキーとデータキーという言葉が出てきます。そうです、KMSが扱う鍵は2種類あるんですね。 2つの鍵の違いは何か? どう使い分けるのか? などが、ぱっと見ではわかりづらいかもし
発表時の資料 本記事に関する発表資料はこちらです。 ※ プラットフォームバージョン1.3以上の場合 この記事はプラットフォーム1.3より前を使用する前提で記載しています。 1.3以上をお使いになる場合は、こちらの記事をご覧ください。 https://devblog.thebase.in/entry/2019/01/16/110000 目次 クレデンシャル情報の扱い方 概要構成 具体的な手順 参考資料 クレデンシャル情報の扱い方 クレデンシャル情報の扱い方を考えるに当たり、Beyond the Twelve-Factor Appというクラウドネイティブアプリケーションの設計パターンについて説明した資料がよく参照されています。 上記の資料内の「05. CONFIGURATION, CREDENTIALS, AND CODE」という章で次のように記載されています。 「今すぐにでもコードをオープン
こんにちは、エムスリーエンジニアの園田です。 エムスリーでは医療・ヘルスケアサイト向けのコンテンツ配信システムであるChuoiというサービスを運用しています。 以前このブログでも紹介しましたが、このサービスは Elixir/Phoenix で実装されていて、ElasticBeanstalk のCustom Platformを使って運用していました。 www.m3tech.blog 2018/07/04 に AWS Fargate が東京リージョンでローンチされたので、ElasticBeanstalk から Fargate での運用に切り替えました (2018/07/13 切り替え完了)。その際の手順やTipsを書きたいと思います。 今回は構成の説明のみで、実際のコードなどは別のポストで解説していきます。 2018/07/30 追記 実装編の記事を書きました。 www.m3tech.blog
先日書いた AWS の勉強方法をまとめた記事(AWSを学ぶ上でやってよかった勉強法5選 - log4ketancho)で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「2)簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります!業務で使う分にはサーバー何台立てようが気になりませんが(は言い過ぎですがw)、個人でサービスを運営する場合はそうはい
こんにちは、お肉が食べたいです。齋藤です。 今回はAWS SAM Local と LocalStack を使って ローカルでS3と連携するようなAWS Lambdaのコードを動かしてみます。 SAM LocalやLocalStackの個別の内容については以下の記事などをご覧ください。 今回はそれらのツールについての解説は行いません。 [新ツール]AWS SAMをローカル環境で実行できるSAM Localがベータリリース LocalStackをつかってローカルでLambdaを実行してみた LocalStackを使ってテストをしてみた LocalStackを使ってCIでKinesis Client Libraryを使ったコードのテストを書いてみる Firehoseを使ったコードのテストをLocalStackを使って動かしてみる! 今回動かすアプリケーションはAPI Gateway経由で起動され
おはようございます。一番よく使うemojiは 👀 (:eyes:) のうなすけです。 さて弊社では、最近社内Railsアプリをひとつ構築しました。それをECSで運用することにしたので、そこに至るまでの経緯、つまづき、これからの課題などなどを記事にしていこうと思います。上の図は現時点での簡単なAWS上での構成図です。 以下、見出しは時系列順でやったことを記録していきます。 社内Railsアプリ、一体どんなもの? ここで新規に構築することになった社内Railsアプリですが、特に凝ったことはしていない単純なRailsアプリです。初めからECSで運用することにしていたので、開発環境も全てDockerで構築しています。Railsのバージョンは5.1.0、Docker imageのFROMにはruby:2.4.1-silmを採用しています。 Docker imageのtagについて developm
はじめに 現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。 税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。 そういった中、各アプリケーションをDocker化することでインフラとしては共通基盤としてのDockerクラスタのみの管理になり、運用コストが下がるのではないかという仮説からDocker化を進めることになりました。クラスタを実現するに辺りKubenatesなどの選択肢もありましたが、今回はECSを選択し、下記のようにAWSの
おことわり 主観であり何らかのデータにもとづいてはいない この記事に書いてあることは信じずに自分で試そう EC2 t2 ファミリーは他ファミリーと比べて不安定 どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確率が非常に高い気がする なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる 追記: CPUクレジット理解していないだけではとか書かれていたんですがその辺は確認している。 t2の可用性が問題になったケースいくつかあるんだけど、自分の場合はネットワークがたまに断する問題が多くて、分散DBクラスタの死活監視で1secごとにpingするだけでCPUは常に1%以下みたいなものとかに使うとカジュアルに10
こんにちは、VOYAGE GROUP システム本部の @s-tajima です。 PHPカンファレンス2016 の「老舗メディアが改善に取り組んでいる話」でもお話した通り、長年オンプレミス環境で稼働してきたECナビを、AWSに移転しようというプロジェクトが進行しています。 そしてなんと先日、約24時間のメンテナンスを経てECナビの本体(Webサーバ, 管理画面サーバの一部, データベースサーバ)がAWSに移転しました! AWS移転において得た知見, 構築したシステム等は数多くありますが、今回はCloudFormationとTravis CIを用いて 生産的 で 安全 で 手軽 なAWSのCI環境を構築したお話です。 背景 ECナビは、500万人を超える会員を抱えたVOYAGE GROUPが運営している中でも特に大きなメディアの1つです。 今回、そんなECナビのインフラ調達期間の削減、検証環
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く