新規プロダクトでKubernetesを中心にCloudNativeなアーキテクチャのインフラを導入した話 | Tech Blog
新規プロダクトでKubernetesを中心にCloudNativeなアーキテクチャのインフラを導入した話 Tech Blog 2019.08.26 はじめに アドテク本部Airtrackチームの横山（@nnao45）です。 チーム内ではScala書いたり〜K8Sと遊んだり〜AWSったり〜しています。 この度Airtrackチームの新規プロダクトでKubernetesを採用し、本番環境に投入したのでその知見を共有させた頂きます。 おしながき 目指したアーキテクチャ Kubernetes周り ミドルウェア CI/CD 監視 感想 目指したアーキテクチャ 妥協はしないが身の丈にあったコンテナプラットフォーム って感じですかね。 Kubernetes周り サービスレイヤひとまわり Airtrackチームで広告系完全新規プロジェクトの立ち上げに Kubernetes中心にクラウドネイティブなアーキテ
Amazon EKSでgRPCサーバを運用する - 一休.com Developers Blog
以前の記事でも紹介した通り、一休では、gRPCを使ったサービスを導入し始めています。 user-first.ikyu.co.jp この記事では、このサービスをAmazon EKSで提供するための設計や気をつけたポイントについて紹介します。 背景 一休では、ウェブアプリケーションの実行環境としてAWS Elastic Beanstalkを採用しています。 そして、この4月からElastic BeanstalkをAmazon EKSへ移行するプロジェクトを進めています。 このgRPCサービスもElastic Beanstalkで運用をしていましたが、以下の問題を抱えていました。 適切にロードバランシングできない。 Elastic BeanstalkでgRPCサービスを運用しようとするとNetwork Load Balancer(NLB)を使うことになります。NLBはレイヤ4のロードバランサです
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
AWS 東京リージョンで発生した大規模障害についてまとめてみた - piyolog
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間（EC２） 約６時間 2019年8月23日 12時36分頃～18時30分頃（大部分の復旧） 障害発生時間（RDS） 約９時間半 2019年8月23日 12時36分頃～22時5分頃 障害原因（EC２） 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン（AP-NORTHEAST-1）の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊４データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
AWSのMFAの仕組みを実装して読み解いてみた | DevelopersIO
最近認証や認可の話題が度々でていますね。 ふとAWSのMFAはどのような実装になっているか気になったので調べて実装してみました。 MFAについて MFAの設定は済んでますか。もしまだの方や、うろ覚えの方がいましたらこちらの記事を先に見て設定することをお勧めします。 IAMユーザーのMFA（多要素認証）は有効になっていますか？現状を確認→是正→適切な状態を維持するまでの流れを整理してみた MFAの設定が終わったところで、本題に入っていきましょう。 AWSの多要素認証のページを見るとこんなことが書いてあります。 オープン TOTP スタンダードをサポートするアプリケーションを実行するスマートフォンやタブレットをご使用ください。 https://aws.amazon.com/jp/iam/details/mfa/ オープン TOTP スタンダードは何かわからないですが、私たちは、MFAのためにA
RDS for MySQLで変更すべきパラメータチューニング - なからなLife
呼ばれたきがしたので soudai.hatenablog.com なお、InnoDB限定のお話ですよ。MyISAMを（システムテーブル以外で）使ったことない若輩者なので。 ちょっと余裕がないこともあり、思いつく最小限のことだけ書きます。追加で思いついたら後ほど＆温かいフォロー（というマサカリ？）歓迎。 checkpointに影響がある値 innodb_log_file_size Redoログのファイルサイズです。 生MySQLのデフォルトは「50331648 Byte（48MB）」、RDSのデフォルトは「134217728 Byte（128MB）」。大きなバッチ処理がなければ間に合うかも知れないですが、広げたほうがよいでしょう。 適切な値の範囲は、1M バイトから 1/バッファープールの N 番目のサイズまでです。ここで、N はグループ内のログファイルの数です。 https://dev.m
Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 | Amazon Web Services
Amazon Web Services ブログ Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかも
マルチプラットフォームで利用可能なOpenJDKのAmazon Correttoが発表されました！ | DevelopersIO
マルチプラットフォーム（ubuntu、RHEL、Windows、MacOS）対応のLTSがついたOpenJDK互換のJavaリリースのアナウンスです！ しばらく前に、Amazon LinuxでのJavaのLTSが発表され大きな話題となりました。 Amazon LinuxでのJavaのLTS (Long-Term Support)提供について 「ほぇー、AWSもやりおるやんけ！！」と感慨にふけっていたら、それの100倍ぐらい衝撃的なニュースが、Javaの神様James Goslingのツイートで飛び込んできました。 Just announced #amazon #Corretto at #devoxx. It is our distribution of OpenJDK. https://t.co/09cuPEqnex — James Gosling (@errcraft) 2018年11月
AWSを使うときに確認すべき52のセキュリティチェック項目と15分でできる簡単なチェックの方法｜DevelopersIO
はじめに 自分が使っているAWS環境のセキュリティに問題がないかと心配になることはないでしょうか？私はよくあります。そこでCIS Amazon Web Service Foundations Benchmark というAWSのセキュリティのガイドラインに沿って使っているAWSアカウントのセキュリティの状況をチェックしてみました。チェック項目は全部で52あります。内容を一通り確認したところ知らなかったAWSのセキュリティの機能やノウハウを知ることができ、見ただけでもとても勉強になりました。簡単にチェックする方法も併せて紹介しますのでぜひ使っているAWS環境でチェックしてみてください。 1 IAM 1.1 rootアカウントを利用しない rootアカウントは強力な権限を持つため、rootアカウントを利用せずIAMユーザーを利用してください。通常運用でrootアカウントが利用されていないか確認し
AWSから120万円の高額請求が来た話
筆者は2018年の夏にAWSから高額請求を受けました。 とある開発合宿の夜、LaravelでS3に画像をあげ、CroudFront経由で表示させるための実装を行っていた時の出来事です。 AWSのコンソール画面とにらめっこしていた時に、ふと左サイドバーの履歴の項目に、気になる項目が目に付きました。 ん？ 請求？ 普段はこんな項目出て来ないため、気になったのでクリックしてみました。その瞬間、恐ろしい現実を目の当たりにしたのです。 請求を押した時に開かれた画面が、以下の通りでした。 【請求画面の画像】 及び10000$！日本円にして、約124万円の請求が来ていました。 何かの間違えだと思ったが、少し怖くなったのでひとまず、こういった事例がなぜ起こるのか、自分に当てはまる原因がないかを調べるため、「AWS 高額請求」などでググってみました。 すると、いくつか記事が早速上位にヒットしました。 htt
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
【AWS】アカウント契約の準拠法をワシントン州法から日本法に、管轄裁判所をワシントン州キング郡州裁判所から東京裁判所に変更する方法 - Qiita
【AWS】アカウント契約の準拠法をワシントン州法から日本法に、管轄裁判所をワシントン州キング郡州裁判所から東京裁判所に変更する方法AWS要件定義契約非機能要件AWSArtifact はじめに AWSを利用しているプロジェクトのリーダーは一読ください。 AWSアカウント契約の準拠法と、管轄裁判所を変更する手順をまとめます。 お客様のAWS環境を自社が代行して契約しているようなケースの場合、米国法のままになっている可能性があります。後述するAWS Artifactから、本番環境で使用しているAWSアカウントの準拠法を確認することをお勧めします。 AWSを使うプロジェクトでPLが意識すること RFPや要件定義時の非機能要件の確認事項として、「クラウドサービスの準拠法が日本法であること」 を確認されたほうが良いと思います。 AWSとの契約のおさらい AWSは米国企業であるため、たとえ東京リージョン
WebSocket対応した噂のALB (Application Load Balancer) を試してみた - tail my trail
TL;DR 2016年8月にAWSのLoad Balancerが WebSocketに対応した スムーズすぎて心配になるくらい簡単に導入できる 「うまい、はやい、やすい」ので、導入しない理由はないと思う ALB Release! 巷では長らく噂になっていた、新しいAWSのLoad Balancer。 先月2016年8月11日についにリリースされた。待望のL7対応だ。 個人的に魅力の一つだったのはWebSocket対応。 従来のELBではWebSocket通信を終端できなかったため、 WebSocket通信の負荷分散/バランシングを行ったりSSL/TLS化する場合、 自前でバランシングする仕組みを実装したり、Nginxを前段に配置するなどちょっとした工夫が必要だった。 AWSのLoad BalancerがWebSocketサポートしてくれるのであれば、この設計構築および運用をアウトソース出来
ALBでTLSネゴシエーションエラーが出たのが困った話 - Qiita
ことのはじまり サイトのアクセス数が日に日に増えていく中で、どうも一部のアクセスが502エラーになっていると、Mackerel監視でアラートがあがってきました。 とりあえずApacheリスタートをしてみたり、リクエストを別サーバに逃がしてみたりしてみたものの、事象は改善しませんでした。 時同じくして、Mackerelを見ていたら、こんな状態に...（弊社サイトは2台のEc2で冗長構成） 2台とも落ちてる... すぐに画面から弊社サイトを確認してみても、ちゃんと表示できました。 なぜ、2台とも落ちてるのに、画面が表示されたのか分からなかったのですが、 調べていくうちにわかった「なるほどー」を書いておきます。 （そもそも問題を解決しないといけないので、それもあわせて書いておきます。） 何が起きていたか アクセスが増える ↓ Apache側のプロセス生成が追いつかなくなる ↓ TLS ネゴシエー
OSS 版 Redash を Docker と AWS でセキュアに運用する - JX通信社エンジニアブログ
VPoEの小笠原(@yamitzky)です。 JX通信社では、NewsDigest や FASTALERT の KPI 管理や、データ分析の用途などで、 Redash を活用しています。 ただしセキュリティ上の観点から、Redash の OSS 版をプライベートなネットワーク内で運用しています。セキュリティ的には良いのですが、機能的な面ではマネージド版に劣る部分があります。例えば、Slack の bot や、Google Spreadsheet との連携などはできなくなってしまいます。そこで、新しくOSSを作ってこれらの課題を解決しています。その他にも、通常のマネージド版にはない機能を拡張したりもしています。 ２年半 Redash を運用して溜まった知見を紹介します。 Docker クラスター上での Redash のホスト JX通信社のインフラは、基本的には AWS 上にあります。 Red
運用担当者のためのAWS改善マップ | DevelopersIO
Trusted Advisor AWS Trusted Advisorは、コスト、パフォーマンス、セキュリティ、耐障害性、サービスの制限について、アドバイスしてくれるサービスです。 サポートプランによって、チェック項目が異なります。 セキュリティについては、セキュリティグループの無制限アクセス、S3バケット許可などをチェックしてくれます。 セキュリティについては、赤の指摘項目は0にしましょう。 insightwatch insightwatchは、弊社が提供するサービスです。 AWSアカウントが、ガイドラインに沿ったセキュリティのベストプラクティスで運用されているかチェックします。 複数アカウントをチェックしやすいため、たくさんのアカウントを運用されているかたに特にお勧めします。 どなたでも無料でご利用いただけます。 IAMの見直し、定義 IAM のベストプラクティスに基づいた見直しを行い
Rails × ECS でオートスケーリング＆検証環境の自動構築 - メドピア開発者ブログ
マリオカートでカーブを曲がるときに体を傾斜させてしまうCTO室 kenzo0107 です。 今回は 2018/04/02 にリニューアルしたイシコメの Rails × ECS についてです。 イシコメとは？ 「イシコメ」は、医師10万人の声でつくるヘルスケアメディアです。 医師と一般の方々をつなげることで、医療情報格差を埋めることを目指しています。 MedPeerの10万人の医師会員に協力いただいたアンケート結果をもとに編集部で記事を執筆し、医師監修の上で配信。多くの医師の声を反映することで、より正しい情報を提供しています ishicome.medpeer.jp リニューアル経緯 リニューアル前は以下のような構成でした。 フロントに Laravel 5 バックに Drupal Docker on EC2 コンテナイメージの S3 でのプライベート管理 Docker がまだ出てきて間もない頃
Well-Architectedなアーキテクチャが大集合！ Startup Architecture of the year 2018に輝いたのは？【AWS Summit Tokyoレポート】
6月1日、AWS Summit Tokyoの最終日にスタートアップのピッチコンテスト「Startup Architecture of the year」が開催された。ビジネスを支えるシステムアーキテクチャに焦点を当て、スケーラビリティの担保や先進技術の取り入れ方、セキュリティへの取り組みなど、さまざまな観点からWell-Architectedなアーキテクチャを選出する。一般公募から厳しい一次選考を勝ち抜いたスタートアップ企業7社が登壇し、現役CTO100人が選ぶグランプリをはじめ3つの賞を争った。果たして誰が栄光に輝いたのか。当日の様子をレポートする。 100人の現役CTOが、自らの経験と確かな知見で選ぶ”Startup Architecture of the year” 厳しい選考を勝ち抜いた、スタートアップ企業のエンジニアたち スタートアップ向けのピッチコンテストは、ビジネスモデルにフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSマンガ 全話を読む| AWS
