AWS の API を利用するときに気をつけたい 3 つのポイント | はったりエンジニアの備忘録
AWS の魅力は API を使ってインフラをコントロールできる点です。インフラだけでなく SQS や DynamoDB といったサービスも API で操作します。ほぼすべてのサービスに API が用意されているので、AWS を使いこなせば使いこなすほど API の利用頻度も上がります。 今回は AWS の API を利用するときに気をつけたいポイントをまとめてみました。 リトライ処理を入れる AWS に限ったことではありませんが、API リクエストはさまざまな理由で一時的に失敗する可能性があります。クライアント側のネットワークエラーの可能性もありますし、大量のリクエストを送ってサーバ側でスロットリングされているかもしれません。 なので、API リクエストは 一時的な失敗を前提 にリトライ処理を入れましょう（AWS SDK を利用しているのであればリトライ処理は自動的に行われます）。一度失敗
AWSの処理速度が遅い理由
現在、サーバシステムの開発を行っております。 デスクトップPCで開発を行い、ある程度完成したところでAWSに移動しところ、 下のように遅くなりました。 ※あまりに遅かったため、いろいろ試しました。 デスクトップPC→1秒 m3.large→5秒 c3.large→5秒 c3.xlarge→5秒 c4.8xlarge→3秒 ※通信時間は除く CPU的にはデスクトップとAWSでそこまで差はないと思いますが、AWSに苦手な処理等が あったりするのでしょうか？ 知見のある方はご教授ください。 【補足情報】 デスクトップSPEC CPU:Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz RAM:8GB OS：Ubuntu12.04(AWS,デスクトップ両方) 開発言語：java(jar実行)
2016年 GCE vs AWS：何故Amazonを絶対使ってはイケナイのか！
Lv：23 Exp：110755 徳島県出身、吉積情報株式会社最高技術責任者 愛光高校、東京大学卒業後、アクセンチュアにて5年間システム開発を経験。 CP300のアジア初取得者。 Google基盤上でのシステム開発の普及を目標として日々活動中。 はじめに この文章は典型的なWebスタートアップにおける私の経験によるものです。我々はAWS上で100以上のインスタンスを起動させ、一定のペースで成長してきた中である程度の期間そうやってきました。 我々の全てのオペレーションはクラウド上で行われています。Webサーバ、データベース、マイクロサービス、git、wiki、BIツール、監視、、、これらは全て典型的なテクノロジー会社では必要となるオペレーションです。 後はオフィスにはインターネットアクセスのために少しのスイッチと一つのルータがあるだけで、以上です。オンサイトにはサーバは1台もありません。 以
Amazon EC2 Instance Comparison
API Name Instance Memory Compute Units (ECU) vCPUs GiB of Memory per vCPU GPUs GPU model GPU memory CUDA Compute Capability FPGAs ECU per vCPU Physical Processor Clock Speed(GHz) Intel AVX Intel AVX2 Intel AVX-512 Intel Turbo Instance Storage Instance Storage: already warmed-up Instance Storage: SSD TRIM Support Arch Network Performance EBS Optimized: Baseline Bandwidth EBS Optimized: Baseline Thr
広告業界は終わらない
広告業界で働いている。 大きな会社ではないが、誰もが知るような広告代理店と一緒に、誰もが知るような大企業の広告を手がけている。 一言でいって、この業界のやつらはクソだ。 クソな慣習がクソな若手へ脈々と受け継がれているクソな業界だ。 それでも広告が好きでこの仕事をしている。 無駄が多すぎる無駄な待機、無駄な打ち合わせ、メールですむような内容でも、身体を拘束したがる。 時間と体を案件に委ねるのが誠意であり、face to faceで過ごす時間こそ、価値があると思っている。 パソコンも携帯電話もあるのだから、ただの連絡待ちなら自宅で待てばいい。 ほとんど無言の打ち合わせを長時間するぐらいなら、必ずアウトプットを持ち寄る決まりを作ればいい。 でも、しない。 なぜか？時間と身体的拘束こそ、最大の忠誠だから。 サクっと終わらせたら、やる気がないみたいだから。 ばーかばーか！ 飲み会が長すぎる打ち上げ、
プリセールスエンジニアこそ人類最強のエンジニア - Qiita
私はアプレッソで主にDataSpiderという製品のプリセールスエンジニアをやって10年になります。さすがにタイトルは煽りすぎだよと自分自身で思いますが、それでも普段の仕事の中でプリセールスって仕事は多種多様なスキルを求められる非常に奥深い役割だなと思うことがよくあります。 今回はその辺りを改めてまとめてみて、プリセールスエンジニアかっこいい！と思わせて、プリセールスエンジニアの地位向上を狙いたいと思います。 プリセールスエンジニアとは プリセールスエンジニアとはどのような役割のエンジニアでしょうか？ 素直に定義すると以下のようになるかと思います。 製品やサービスを導入する前の顧客に対して、製品やサービスの技術的な説明やアドバイス、また技術支援を行い意思決定を促進するエンジニア このような職種のエンジニアは外資系の企業によくいます。名前はそれぞれで以下のような名前を持っていることが多いです
書評: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 - Qiita
発端 去年、Naoya Ito さんがこんな話(System of Record と System of Engagement)をした後、SOEとかSORとか話題になることも多くなったと思う。 そんな折、ちょうどいいタイミングで、SOR中のSORなシステムである銀行システムの話を、日本における銀行システムの曙までさかのぼってまとめた本が出たのでさっそくゲットした。 Title: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus) Publisher: 技術評論社 (Feb. 2, 2017) Author: 星野 武史 (著), 花井 志生 (監修) ISBN-13: 978-4774187297 Publish Date： 2017/2/4 Amazon: https://www.amazon.co.jp/dp/477418
microインスタンスのCPU使用率はCloudWatchを信じろ - 日報 #113 - 俺の報告
解せぬ解せぬと思っていたことがようやく分りました。 嬉しい半面、異常に時間をロスしたことに地団ステップを踏まざるを得ません。 結論から先に書きます。 しかも箇条書きで。 t1.microのtopコマンドやvmstatでのCPU使用率は信じるな t1.microのCloudWatchのCPU使用率を信じろ かと言ってt1.microのvmstatコマンドとかから実際のCPU使用率を計算することはかなり難しい。（実質無理？） 安定してCPU監視のもと動作させたいなら、smallインスタンスから使え ということです。 サービスレベルでmicroを使う時は注意が必要というのは、 一見当たり前のようですが、 今回はその中でも重箱の隅をつつくような理由で説明させていただきます。 もちろん、下記の情報を知った上で上手にmicroを使えるのがハイパーいいことだとは思います。 さて、では簡単に説明を。 こと
2年半を費やしたチャットワークのScala移行、もしやり直すならどうしますか？（後編） | HRナビ by リクルート
トレタCTOの増井雄一郎さんがチャットワークのScala化プロジェクトのお話を掘り起こすインタビューの後編です（前編はこちら：チャットワークのScala移行と大規模メッセージDB再構築、本当にできたんですね！）。ChatWork CTOの山本さんは2年半を費やしたプロジェクトを振り返り、「やっぱりScala化は必要だった」と語ります。 山本 2014年4月ぐらいにScala化を決断して、社内で勉強会が立ち上がりつつ、採用をかけていった感じです。2014年7月に加藤潤一（「日本Scalaユーザーズグループ」発起人のひとり）というScalaの優秀なエンジニアが入ってくれて。そこから設計をどうしよう、と始まって。しばらくは加藤と、もう1人ぐらいで設計をしていた。それが半年ぐらいあったのかな。 2015年ぐらいから実装を始めて。1年でチームメンバーも増えて、そのときは全部まるっと移そうと計画をたて
チャットワークのScala移行と大規模メッセージDB再構築、本当にできたんですね！（前編） | HRナビ by リクルート
2016年8月、トレタの増井雄一郎さん（「IT芸人」「フログラマー」で検索！）はPHPからScalaへの移行を表明していたChatWork CTOの山本正喜さんに「本当にScala化できるんですか？」と直球で聞きました（「PHPからScalaに乗り換えたチャットワークさん、その後どうですか？（前編）」）。そして2017年2月。「移行できたら、ぜひもう一回来てください」との誘いを受けて、再び増井さんがチャットワークにやってきました！ 増井 Scala化、おめでとうございます！ 山本 ありがとうございます。 増井 前回も聞きましたが、読んでない方もいるでしょうから、もう一度聞かせてください。Scalaを入れようと思った時期はいつなんでしょうか。 山本 そのあたりはBlog（「チャットワークがScalaを採用する理由、これからのチャレンジ。」）に書いたんですが、2年半前──合宿をしてScala化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
