memcachedからElastiCacheに切り替えた | ogaworks
いつも使っているサーバ環境は、基本的にAmazonのAWSなんですが、最近、使用中の一部インスタンスでリージョンの移行手順を検証してます。 移行元は”US-East”のバージニアリージョンで先は”Asia Pacific”の東京リージョン。 というのも、”US-East”で使っている一部インスタンスのAvailability ZoneのReserved Instanceが購入できなくなって、このままだと比較的割高なオンデマンドインスタンスの状態が継続してしまうためです。 同じリージョンの別のAZに移行して対処でもいいんですが、どうせならレイテンシの改善もということで、東京に逆輸入することに。 インスタンスはAMIの状態でリージョン間コピーして、EBSはrsyncでコピーしました。 そして、hostsやらhostnameやらIP書いてるconfファイルやらをざっと書き換え。 US-Eastで
スタイルシートをめぐる冒険: inline-blockの奇妙な世界
inline-blockとは、displayプロパティの値のひとつで、表示形式を「インラインに流し込むことのできるブロック要素」にするためのもの。まともに対応しているのが、OperaとSafari、それになぜかMac版IEくらいというマイナーな存在だが、なかなか興味深い振る舞いをする値なので、いろいろと検証してみた。 まず、「インラインに流し込むことのできるブロック要素」とはどういうものなのかを見てみるために、.inlineblockというクラスを作り、div要素に指定してみた。また、「インラインに流し込むことのできるブロック要素」とは、言い換えれば、「幅と高さを指定できるインライン要素」ということだから、span要素にも指定した。 インラインブロックの検証 その1 【スタイルシート】 .inlineblock { display: inline-block; width: 100px;
「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
インフラエンジニアに贈るAmazon VPC入門 #1 概要とルーティング | DevelopersIO
ども、大瀧です。6月にNothing's Carved In Stoneの新譜が出ると聞いてテンション上がっている今の勢いを生かし、シリーズものにチャレンジしてみます。 シリーズの目次はこちら 前振り(読み飛ばし可) インフラエンジニアのみなさーん、AWS触ってますかー? 「うちのシステムはAWSを使っていない」、「AWSじゃない国産クラウドを使う予定」など、AWSの認知度は一般にはまだまだ低いのが現状だと思います。しかし、組織のインフラは今後遅かれ早かれ、オンプレミスだけでなくクラウド環境と合わせて付き合っていかなければならないことは明らかですし、先行しているAWSの技術が他のクラウド製品のコンポーネントに与えている影響も、実はとてつもなく大きかったりします。 現状、多くのクラウド製品では、クラウドで利用できる機能を説明するときに"●●版S3"、"●●版セキュリティグループ"というように
ベンチャーで働くエンジニアに必要な「勇気」 | Nekoya press
「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業（はすぐ辞めたけど）を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと
2013年版! SonicGardenにおけるherokuでのサービス運用構成 | mah365
ちょうど去年の今頃、SonicGardenにおけるherokuでのサービス運用構成をご紹介しました。去年の比較して、今ではherokuで本番運用されているサービスも増えているかと思いますが、実際の構成例はあまり紹介されていないようです。去年ご紹介した内容も少し古くなっていますので、2013年バージョンとして、再度ご紹介したいと思います! 去年からの変更点 去年と比較して大きく変わっている点は、以下の3点ですねー。 バックアップ取得方法の見直し & 監視の導入 Route53愛してる! ログ取得のアドオンをPapertrailに変更 バックアップ取得方法の見直し & 監視の導入 @interuが去年のJAWS-UG in Nagoyaで講演したように、「本当にバックアップ取れてるの？」というのは重要な視点ですね! なので、バックアップを取得するところと、監視するところ、セットで構成するように
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeveloperKnowhow.com is for sale | HugeDomains