エンジニア組織の成果を伝えたい!経営層や非エンジニア組織との会話、どうしてる? / How do you communicate with management and non-engineering teams?
2020/01/20 Update: 本エントリの内容は2019年12月3日にアナウンスされた『Amazon RDS Proxy』のリリースにより完全に陳腐化しました。過去のアンチパターンがフィードバックをもとにした改善によってアンチパターンではなくなるという最高の事例です。 サーバーレス元年始まった! 今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから. ・カスタムランタイムで実質どんな言語でも利用可能 ・VPC利用時のコールドスタート改善 ・Provisioned Concurrencyでスパイク対応も可能 ・RDS ProxyでRDBとの接続が現実的に これまで5年で受けたフィードバックがついに結実. 強い— Keisuke Nishitani (@Keisuke69) 2020年1月19日 RDS Proxyの詳細はこちらからどうぞ。まだプレビューですがぜひ試して
AWS SDK for node.jsのデベロッパープレビュー版がリリースされたので触ってみた。 AWS SDK for Node.js (Developer Preview) http://aws.amazon.com/jp/sdkfornodejs/ まだデベロッパープレビュー版なのですべてのサービス向けのAPIが実装されているわけではなくて、現状EC2、S3、DynamoDB、SWFのみに対応済みな状態。こんな感じ↓ 何をしてみようかというところで、S3を取り扱うようなサンプルコードはちょいちょい見かけるのでDynamoDBを扱って見ることに。socket.ioを触ったことがなくて、触ってみたこともあって、http://www.atmarkit.co.jp/ait/articles/1210/10/news115.htmlを参考にチャットアプリケーションを実装してみた。アーキテクチャ
CTOの椎名アマド ( @ima_amataro) です。 前回の記事:「Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話(1)」 前回はRedisをチャットのプライマリのストレージとして使う上での問題点と、 Amazon DynamoDB の特徴などを紹介しました。 今回はDynamoDBの詳細説明と、実際の移行作業と、その際にハマった点をお話していきます。 DynamoDBのテーブル構成 まずは DynamoDB 上のテーブル構成を考えるところから。 Redisにおいてはシンプルな list にチャットを保存していて、 chat.room.{room_id} {timestamp}:{user_id}:{urlencode(message)} {timestamp}:{user_id}:{urlencode(message)} {tim
2ヶ月以上前ですが、Rack アプリケーションで DynamoDB を セッションストア用として使うための gem が公開されていました。 DynamoDB Session Store for Rack Applications Rails だと ActiveRecord のセッションストアがありますが、RDB なので、どうしても気になるのは負荷と障害ですね。 そんな時は、スケーラブルかつ耐障害性に優れた DynamoDB を使って解決しましょう。 *1 ということで、Rails4 で DynamoDB をセッションストアとして使う方法を試してみました。 Rails アプリケーションの作成 先ずは Rails アプリケーションの作成です。 $ mkdir try_dynamodb_sessionstore && cd try_dynamodb_sessionstore $ bundle i
CTOの椎名アマドです。 今回は、Pairyのチャットデータを全てRedisからAmazon DynamoDBに移行した話をしたいと思います。 我々が 2012年6月に カップル専用アプリ Pairy をリリースした時には、 データベースは MySQL と Redis の両方を利用するところで始めました。 Redis の役割は: 1. MySQLレスポンスのキャッシュ 2. プッシュ通知等のキュー 3. チャットのデータを全保管 サービスローンチ直後はまだ Appサーバー(EC2)1台と、MySQL & Redisを両方走らせてる DBサーバー(EC2)1台で十分だという判断で、しばらくはそんな構成でやってました。(S3などは省略) しかし、いざサービスが成長してくるともちろん MySQL & Redis を1台でまかなうのはキツくなり、MySQL と Redis を別々のEC2インスタン
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました! スティッキーセッション ロードバ
Amazon DynamoDBとは? Amazon DynamoDBは、シームレスに拡張ができ、高速で予測可能なパフォーマンスを提供する、フルマネージドのNoSQL(非RDBMS)です。これは、データベース管理、パフォーマンス、スケーラビリティ、および信頼性のコアな問題に対処するために設計されています。Amazon DynamoDBは、お客様が少額の料金を支払うことによって、高可用性データベースのスケーリングとオペレーションの管理負担を軽減します。 Amazon DynamoDBのサービス特徴 Amazon DynamoDB スケーラブル スループット供給 自動ストレージ拡張 完全に分散された非共有アーキテクチャー 高速で予測可能なパフォーマンス 容易な管理 フォールトトレラント済み フレキシブル 強い一貫性、原子性 費用対効果のある セキュア モニタリング EMR(Elastic Map
DynamoDBはSimpleDBとほぼ同様の使い勝手の低レベルAPIのほかに高レベルAPIが最初から用意されているのがポイントだ。 低レベルAPIについては前回紹介済みなのでそちらを参照。 http://d.hatena.ne.jp/shin/20120125/p1 高レベルAPIはEntityのマッピングがある。 構成は前回と同様。 テーブル名は「testdb」主キーは「id」という項目名で数値型。もうひとつが「名前」という文字列型。 マッピングクラス マッピングするクラス。プロパティ名が項目名と同一の場合ゲッターに対してのアノテーション付与は必要ない。ただし、キーの設定だけは保存時などに必要。フィールドに対しては効果がないので注意。いまどきのフレームワークは大抵フィールドでも動くからね。 @DynamoDBTable(tableName="testdb") public class
ひさびさのJavaネタ。 Amazon Web ServicesからオールSSDによる性能(キャパシティ)を自由に設定可能なデータベース、DynamoDBが発表されました。 キャパシティを自由に設定可能ってことは、一時的にバッチを走らせたいというときにキャパを上げて短時間で終わらせるとか、空いている時間に少しずつ流していくとかいうテクニックが使えそうです。また、こちらが通常の使い方でしょうが、負荷の高い夜にはキャパを上げて、あまり人のいない早朝には下げることによって運用コストを大きく減らせる可能性があります。 これはつかうしかない!100MBまでの無料枠もありますので試すにはうってつけでしょう。 というわけで、試してみたのですが、すでにSimpleDBとか触ったことがある人にとっては何も難しいとか引っかかるところとかなかったですねぇ。SDKの使い方もいつもどおりだし、テーブルとかわかりやす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く