サーバーサイドエンジニアとして2020年に使った技術 | うなすけとあれこれ
2020年のフロントエンドエンジニアの技術スタックの一例 | potato4d D(iary) この記事と、TLで「これのバックエンド版が見たい」という発言に触発されたので書いてみます。口語体と文語体が入り乱れてるのは許してください。 冒頭のグラフはwakatimeで生成した今年1年間のプログラミング言語使用率です。2位はTypeScript、3位はTerraform、4位はYAMLでした。 立場 フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている1都合上、視野が狭いかもしれません。 公開している成果としては クラウドゲーミング最新開発事例 - #CEDEC2020 - Speaker Deck があります。 長年RubyとRailsを書いてきたので、技術スタックがそのあたりに偏っています。
Amazon Aurora PostgreSQL が AWS Lambda と統合
PostgreSQL と互換性のある Amazon Aurora は、AWS Lambda 関数を呼び出すことができるようになりました。AWS Lambda では、プロビジョニングやサーバー管理を行わずに、コードを実行できます。スケーラビリティについて心配する必要もありません。 ストアドプロシージャまたはユーザー定義関数を使用して Aurora データベース内から直接 Lambda 関数を呼び出すことができます。これにより、データベース性能を拡張したり、データ変更に基づいて機能するように外部アプリケーションを呼び出すことができます。たとえば、データベースに入っている顧客のメールアドレスが更新されるごとにメールを送信する Lambda 関数を作成できます。Lambda 関数は、同期または非同期で呼び出すことができます。詳細については、Aurora PostgreSQL のドキュメントをお読み
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/28 最新の障害報告追加] AWS 東京リージョンで発生したシステム障害についてのまとめ - Qiita
AWS東京リージョンで発生したシステム障害について、普段AWSに触れることがない人でも理解できるようにまとめてみました。アップデートがあり次第更新予定です。 8/25 障害の詳細についてのAWSからのメッセージを追記 8/28 追加の障害報告についてのAWSからのメッセージを追記 起こった事象 AWSの東京リージョンにおける単一アベイラビリティゾーン(AZ)に存在する一部のEC2、EBS、RDSにおいて接続できない問題が発生しました。また当該事象が起こったタイミングでAWSのマネジメントコンソール(管理操作画面)への接続もしづらい状況が続きました。 リージョン、アベイラビリティゾーンについて AWSクラウドは現在22の地理的リージョンにある69のアベイラビリティゾーンで運用されています。例えば、米国東部（バージニア北部）リージョンやアジアパシフィック (シンガポール)などが存在します。そし
![[8/28 最新の障害報告追加] AWS 東京リージョンで発生したシステム障害についてのまとめ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3bd2a32abf53502be707e605f70d565b35ce0cda/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCOCUyRjI4JTIwJUU2JTlDJTgwJUU2JTk2JUIwJUUzJTgxJUFFJUU5JTlBJTlDJUU1JUFFJUIzJUU1JUEwJUIxJUU1JTkxJThBJUU4JUJGJUJEJUU1JThBJUEwJTVEJTIwQVdTJTIwJUU2JTlEJUIxJUU0JUJBJUFDJUUzJTgzJUFBJUUzJTgzJUJDJUUzJTgyJUI4JUUzJTgzJUE3JUUzJTgzJUIzJUUzJTgxJUE3JUU3JTk5JUJBJUU3JTk0JTlGJUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgyJUI3JUUzJTgyJUI5JUUzJTgzJTg2JUUzJTgzJUEwJUU5JTlBJTlDJUU1JUFFJUIzJUUzJTgxJUFCJUUzJTgxJUE0JUUzJTgxJTg0JUUzJTgxJUE2JUUzJTgxJUFFJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1kNTc2YjdjY2RhZGNkMWRhMWNlYjJkMDMxNzNiYzNiNQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBUYWlnb0t1cml5YW1hJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00OWJiY2YwMGJjMDAxZjExZWU0NmE0MmExMjJiZmEwZg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D06af76270f9b8dcc6f8866908c300345)
AWS東京リージョンの障害対応について - Qiita
2019年8月23日 AWSの東京リージョンで大規模な障害がありました。 その際に、自社のサービスの維持のために自分がどんな対応をしたのか記録しておきます。 ここから実際の対応記録 影響箇所の特定 まず始めに障害情報をウォッチしているSlackで異変を察知する (この時、優雅にランチタイムでしたが、一瞬でヤバみを感じる) 弊社サービスは一部GCPに遺産を残しつつも、メイン系統を動かしているインスタンス群は、AWSの東京リージョンのものを使用しています。 まずは、EC2上で動いている部分を触ってみる ここでは特に問題は見当たらないので、リージョン全体ではないので、単一AZでの障害であることを察知する (AWSからの障害情報の中でも、単一AZでの障害であったことが明記されています。) 次に、複数台で同時実行されたくないので、あえて単一インスタンスで動かしている部分の動作状況を確認 弊社では、定
【AWS】インフラエンジニアでなくてもできるアクセス負荷対策 - Qiita
こんにちわ、スタートアップで働くサーバーサイドエンジニアです。 メインはサーバーサイドですが、スタートアップなのでインフラやフロントについても担当させて頂く機会が多いです。 そこで今回はTV放送に耐えられるように行った負荷対策とその結果について書いていこうと思います。 AWSなどのクラウドサービスを使えば、インフラ専門の方でなくても随分な対策ができてしまいます。 ぜひサーバーサイドメインでインフラわからないよって方の参考になればと思います！ ①アクセス数の予測 放送される番組の視聴率や放送範囲からアクセス数を予測しました。 (視聴がわからない場合は番組担当者の方に直接聞いたり週間高世帯視聴率番組10 - ビデオリサーチ、テレビ視聴率ランキング | インターネットTVガイドが参考になりました) 計算内容はこちら(参考: カウル Tech Blog) # 総アクセス数を求める公式 総アクセス数
本版のQiitaみたいなサービスを立ち上げた - Qiita
本をベースに独学時のつまずいたポイントを共有 - HITAMUKI 資格、受験、IT、経済、医療など様々な分野で独学している人が本をベースに情報を記録できる。 全部無料。 既存の読書ログサービスは、マークダウンに対応してないから作ってみた。 本のつまずきポイントが集約されれば、後から勉強する人にとって宝の山になるはず! 最終的に、本版のQiitaみたいなサービスになった。 システム構成 マークダウンエディタについて マークダウンエディタは「tui.editor」を利用した。 マークダウンエディアは色々あるけど、「tui.editor」が一番組み込みやすかった。 なにより画像アップロードに簡単に対応できるのが素晴らしい。 デザインについて デザインはbootstrapのサンプル改造した。 bootstrapに対する知識は全く無かったけど簡単に改造できた。 認証周りについて フレームワークにL
Amazon RDS for PostgreSQLにおける自動バキュームのケーススタディ | Amazon Web Services
Amazon Web Services ブログ Amazon RDS for PostgreSQLにおける自動バキュームのケーススタディ PostgreSQLデータベースにおいて、自動バキューム処理(autovacuum)は複数の重要なメンテナンス操作を実行します。周回を防止するためにトランザクションIDをフリーズすることに加えて、デッドタプルを削除し空きスペースを回復させます。書き込み回数の多いデータベースの場合は、自動バキュームを頻繁に実行するようにチューニングすることをお勧めします。そうすることで、テーブルやインデックスを膨らませるデッドタプルの蓄積を避けることができます。 この記事では、デッドタプルが蓄積される状況でどのように自動バキューム処理を監視し、チューニングするかを実際に示すために、ケーススタディを用いてご説明します。 デッドタプルとは何か？ PostgreSQL は同時実
DBリファクタリングをやっているって話 - そーだいなるらくがき帳
言語の勉強会でその言語の話をしない人ランキング堂々の第一位、そーだいです（当社比 控えめに言っても最高な毎度おなじみ #kichijojipm で今日LTする話の補足です。 kichijojipm.connpass.com speakerdeck.com タイトルは出落ちです。 全然最強じゃなくて頑張ってやってるよって話です。 資料がかなり薄いので補足します。 DBリファクタリングについて 26Pは現状です。 MySQLって書いてますが本番はAurora1を使っています。 以降、このDBを 現行DB と呼びます。 ここではオミカレとみんなの婚活はWebサービス名です。 つまり2つのサービスから現行DBを見ていますし、機能によっては現行DBの同じテーブルを参照・更新・削除などを行います。 この2つ以外にも社内システムなどでこの現行DBは利用されており、メインのテーブルを変更すると影響範囲が広
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - middyjs/middy: 🛵 The stylish Node.js middleware engine for AWS Lambda 🛵
GitHub - softwaremill/elasticmq: In-memory message queue with an Amazon SQS-compatible interface. Runs stand-alone or embedded.
SQSでLambdaを蹴るときは気をつけましょうというお話 | Qrunch（クランチ）
GitHub - CodeGenieApp/serverless-express: Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.
GitHub - fastify/aws-lambda-fastify: Insipired by aws-serverless-express to work with Fastify with inject functionality.