Lambda+RDSはアンチパターン - Qiita
何が起きたのか 作成していたアプリではサーバレス構成にてLambdaからRDS(MySQL)を呼び出していました。 リクエストが増えるとRDSのコネクション数が増加して すぐにDBコネクションエラーになってしまいました。 最大コネクションの上限値 結論から言うとLambdaとRDS(MySQL)は相性が良くないです。 理由はLambdaからRDSのDBコネクションを貼ると リクエスト単位でコネクションを張ってしまうため 仕組み上、同時接続に耐えられません （RDSのコネクション上限数が少ない） さらにVPC設定すると・・・ セキュリティのため、RDSをLambdaからのみアクセスさせるためには LambdaとRDSを両方とも VPC領域に置く必要があるのですが、Lambdaの起動が遅くなる場合があります。 これは、一定時間Lambdaがコールしない場合にスリープ状態になり、 起動する際にE
VPC Peeringの設定 - Qiita
VPC Peeringとは 2つのVPC間の通信を外部ネットワーク経由でなくL3ネットワーク経由で、でVPC間の相互に通信ができるサービスです。 VPC Peeringの概要や利用する際の注意点（IPアドレスの重複は避けようとか、は公式ブログが詳しいです。 Amazon Web Services ブログ 【AWS発表】Amazon Virtual Private CloudでVPCピアリング (VPC間接続)が可能に AWS Solutions Architect ブログ VPC Peeringの使いどころとTips等々 Developers.IOブログ Amazon VPC Peeringの技術的考察と留意点 やりたいこと AWSアカウントAのVPC-A(10.0.0.0/16）にZabbix Serverを用意し、AWSアカウントBのVPC-B（10.45.0.0/22）にZabbix
マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita
マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ
S3のアクセスコントロールまとめ - Qiita
これに評価が許可になる条件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
Github issue で質問してはいけない - Qiita
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
MySQL 互換のDB、Percona Server を使う理由 - Qiita
# Time: 120114 6:34:33 # User@Host: user[user] @ [10.10.10.10] # Thread_id: 28313080 Schema: mydb Last_errno: 0 Killed: 0 # Query_time: 0.588882 Lock_time: 0.000068 Rows_sent: 3 Rows_examined: 183839 Rows_affected: 0 Rows_read: 100 # Bytes_sent: 121 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 /+ Percona Server 独自のログ +/ # InnoDB_trx_id: 9903E4DB1 # QC_Hit: No Full_scan: No Full_join: No Tmp
Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
AWSソリューションアーキテクトを目指すための備忘録 - Qiita
IAM role インスタンス起動時に割り当てることができる インスタンスに一つしか割り当てられない 既存インスタンスに割り当てられない 割り当て解除できない Permission変更は即時反映 セキュリティグループ FWのこと インスタンス一つに複数割り当てることができ、ホワイトリスト方式で適応 更新すると即時反映するが、起動中のセッション（要確認）には反映しないので再起動が必要なこともある EC2-Classicを利用している場合はEC2-Classic用のセキュリティグループを使用しなくてはいけない EC2-Classicでは1インスタンスにつき500のグループを割り当てることができる EC2-Classicでは1グループにつき100件のルールを記載できる EC2-VPCを利用している場合はEC2-VPC用ののセキュリティグループを使用しなくてはいけない EC2-VPCでは1インスタ
AWS セキュリティグループのオレオレ設定ポリシー - Qiita
セキュリティグループは、1 つ以上のインスタンスのトラフィックを制御する仮想ファイアウォールとして機能します。インスタンスを起動するときに、1 つ以上のセキュリティグループとインスタンスを関連付けます。各セキュリティグループに対してルールを追加し、関連付けられたインスタンスに対するトラフィックを許可します。セキュリティグループルールはいつでも変更できます。新しいルールは、セキュリティグループに関連付けられているインスタンスすべてに自動的に適用されます。インスタンスに到達できるトラフィックを許可するかどうかの判断では、インスタンスに関連付けられているすべてのセキュリティグループのすべてのルールが評価されます。 by AWS 要するにファイアウォール。 あるある事例 同じ様なポリシーが乱立 AWS担当者が一人の場合にはあまり起こらないが、複数人で設定を行うと同じ様な設定が複数個作られる。特にた
AWSのセキュリティグループにセキュリティグループを指定した時の落とし穴 - Qiita
※ ○：適用される/ ×：適用されない Details 前提 AWS で EC2 インスタンスを起動すると PublicIP/PublicDNS/PrivateIP がふられる。 PublicIP インターネット（外部）に公開されてるIP。例）54.123.456.78 PublicDNS DNSに登録されるホスト名。例）ec2-54-123-456-78.region.compute.amazonaws.com PrivateIP AWSのネットワーク内のみで使えるIP。例） 172.17.123.45 異なるリージョン間では、PrivateIPは使えない。名前解決するとプライベートIP出てくるけど。そんなの関係ない。 きっかけ EC2のセキュリティグループ設定を、必要最低限のネットワークに限定したい。 セキュリティグループにはIPアドレスも指定できますが、基本的に冗長構成組んでるとサー
良く分かるMySQL Innodbのギャップロック - Qiita
MySQLのロック ロックとはトランザクションの並列度を上げる為の並列スケジューリング方法の一つ トランザクションをサポートしているデータベースにおいては、トランザクションの並列数を上げる事が性能アップの一つの方法。 他のトランザクションに更新して欲しくないデータだけにロックをかけて、ロックされたデータ以外を更新するトランザクションは並列で実行される。 Innodbは行ロック？ Innodbは更新対象の行だけをロックする。と思っていると、意外な落とし穴にハマる。 その一つがギャップロック。 ギャップロックを実際に起こしてみる サンプルテーブル idとstrがあるだけのシンプルなテーブル。idがPKで1~5までは順番に、その後、10,20と飛んで行が入っている。 通常の行ロック トランザクション１ select for updateでid=2の行を明示的にロック トランザクション２ id=1
サーバ監視・性能測定ツールまとめ - Qiita
エージェントソフトウェアを対象PCにインストール形でサーバの監視・性能測定を行うツールのまとめ。 SaaSサービス NewRelic アプリケーションの性能測定が簡単にできるSaaS。あちこちで導入実績があってスタートアップではデフォルト担っているようにさえ感じる。各言語でのプラグインだけがあって、自作アプリ外のサービスは対象外なのかと思っていたが、プラグインのリストをみると色々と対応しているようだ。 Good 豊富な実績がある Bad インターネットにつながっていないと利用できない。 参考リンク New Relic Wantedlyを支えるモニタリング DataDog "Cloud Monitoring as a Service"とHPタイトルにしっかり明記されている。後述するMackerelと真っ向からバッティングする海外サービスはきっとこれなんだろうと思う。エージェントはOSSで公開
CloudWatch 標準メトリクス(監視項目) 一覧 - Qiita
標準メトリクス一覧がネットで調べてもなかなかでてこなかったので、備忘録として残しておきます。 参考：http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-cloudwatch.html CPUUtilization 割り当てられた EC2 コンピュートユニットのうち、現在インスタンス上で使用されているものの比率。このメトリックスは、選択されたインスタンス上でアプリケーションを実行するのに必要な処理能力を表します。 単位: Percent DiskReadOps このインスタンスで利用できるすべてのエフェメラルディスクでの、完了した読み取り操作の数（インスタンスで Amazon EBS を使用している場合は、「Amazon EBS のメトリックス」を参照してください）。 このメトリックスは、一定の時間当たりの、アプリケー
Tomcat JDBC Connection Poolの存在を忘れてました - Qiita
はじめに 少し前まで業務でSeasar2 FWを使っていたためコネクションプールはSeasar2のものを利用していました。S2のコネクションプールの実装はシンプルだったし業務で利用していても特にそこがボトルネックになることはありませんでした。 別のプロジェクトに移ってDBCPを触っていたのですが、実装になんとなく疑問を感じたので調べてみました。 tomcat jdbc connection poolとは？ tomcatで実装したConnectionPoolの実装です。（DBCPとは異なります。） tomcat 7.0.19から利用できます。 tomat-jdbc.jarに含まれています。 DBCPからの切り替えはfactoryを変更するだけです。 tomcatのdefaultではDBCPが選択されていますので明示的に変更が必要です。 どこに違いがあるのか。 パフォーマンス DBCPよりパフ
大規模データについて第6回 ～Redshift編～ - Qiita
大規模データについて最後にRedshiftについて書きます。 使い始めたばかりで実践的な話は少ないですが、現場視点の使用感をまとめました。 Redshiftとは AWSが提供するデータウェアハウスです。 いわゆるフルマネージドサービス（RDS、DynamoDBと同様）ですぐに使い始められます。 操作項目はRDSに近いです。 詳しくは、コチラをご覧下さい。 特徴をまとめると 使い勝手は、他のAWSサービス同様に必要に応じて簡単に拡張できます、 データ抽出のためのSQLは、Postgreペースのカスタム版です。 抽出のための機能は揃っているので問題なく使えます。 詳しくは、コチラ をご覧ください。 運用の手間は、バッチ処理の様な比較的時間の余裕がある処理で使う分には問題ないレベルだと思われます。 １時間/週のメンテナンス時間が必要なのでDBが止まっても問題ない(リカバリできる)処理でないと難し
一からマイクロサービスの開発フローを作った話 - Qiita
※ 2016年の記事なので、すでに古い情報が多いです。 今の会社で、全社の外部サービスで利用できるAPIを作ってね、という話があったので、環境構築からコーディング、運用まで一人で行っている。 基本はAWSのサービスを利用し、ログの保存だけGCPのBig Queryを利用した。 ※ 2017/10/13 追記 このときの経験を踏まえて、コンテナでの環境構築を行ったので記録した。 → 一からAPIサーバの開発フローを作った話〜コンテナ編 関連記事 マイクロサービスで調査しやすいログをつくる マイクロサービスのテスト作成方針 マイクロサービス作成時におこなった負荷対策 deployフローに関しての振り返り ウェブサービス構築時に導入する、開発が3倍速くなる仕組み 簡単な要件 ゲームなど自社で利用するユーザアカウント情報を1つにする 現在のアカウントで引き続きサービスは利用できる アカウント以外に
無停止リリース参考 - Qiita
参考サイト 参考ページを加えていく。 データセンター移行に伴い、 MySQLをカジュアルにアップグレードしたお話 クックパッドでのVPC移行について Server Migration with Zero Downtime | Sisyphian Tales Upgrading GitHub to Rails 3 with Zero Downtime – Shay Frendt AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog; 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー Tomcat7 でゼロダウンタイムデプロイ - mallowlabsの備忘録 キーワード 用語が統一されていないので、検索する際のキーワード候補。 ゼロダウンタイム
エンジニアなら知っておきたい、絵で見てわかるセキュア通信の基本 - Qiita
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信を安全に（セキュアに）行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに
GraphQL概要（React Europe2015での発表の簡易まとめ） - Qiita
Lee Byron - Exploring GraphQL at react-europe 2015 - YouTube React Europe 2015内でGraphQLのworking draftとGraphQLサーバのtechnical previewの公開が発表されました。GraphQLのアイデア自体は以前に発表されていたようですが、今回のReact Europe 2015で初めて具体的な仕様と実装が発表されました。 GraphQLはFacebookが開発した、クライアントとサーバ間のデータのやりとりを簡単にするための言語です。 言語だけではなく、GraphQLを使うクライアントとサーバの仕様も含んで「GraphQL」と表現していました。 参考資料 GraphQL GraphQLのworking draft graphql/graphql-js GraphQLサーバのtechni
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
