同意してLinkedInに登録 登録またはサインインするために [続行] をクリックすることにより、LinkedInの利用規約、プライバシーポリシー、Cookieポリシーに同意したものとみなされます。
同意してLinkedInに登録 登録またはサインインするために [続行] をクリックすることにより、LinkedInの利用規約、プライバシーポリシー、Cookieポリシーに同意したものとみなされます。
デフォルト設定で構築してあったAmazon RDSMySQLの運用でちょっと困った事があったので。 SlowQueryを取りたいんだけど? MySQL運用あるあるです。 デフォルトOFFなので必要に迫られてONにするケースは多々あります。 どうぞどうぞ slow_query_log または log-slow-queries スロークエリログの有効/無効 slow_query_log_file スロークエリログファイル名 long_query_time スロークエリログに出力する閾値(デフォルト10秒) この辺りの 動的パラメーター を設定すれば良いのです。 もちろん 動的パラメーター なのでデータベースを停止することなく変更可能です。 では、適用しましょう まず、RDSなので権限が無いためSET GLOBALコマンドでの変更は行えません。 ERROR 1227 (42000): Acces
cloudpackエバンジェリストの吉田真吾(@yoshidashingo)です。 すごしやすい気候で東京湾花火大会も最高にきれいな週末でした。今週はもうお盆ウィークですね、早いもんです。それでは今週も行ってみましょう。 AWS公式 夏休みなのか閑散としてますね。 1. Amazon CloudFrontのPCI準拠 CloudFront、CloudFormation、Elastic Beanstalk、Key Management Service(KMS)がPCI DSS準拠になり、AWSのサービスのうち合計23サービスがPCI DSS準拠になった。 aws.typepad.com 2. AWSがPCI DSS v3.1対応完了 PCI DSSバージョン3.1の下で、レベル1サービスプロバイダの検証が完了した。 AWSの営業経由で2015年版AWS PCIコンプライアンスパッケージが提供
こんにちは。どうですか? さて、よく低温調理器なんて言いますが、色んなのがあって、今回採り上げるものは何なのかというと「容器にセットすることで長時間水温を一定に保つ装置」です。実験室に恒温槽とかあって、あれは恒温槽というひとかたまりの設備ですが、これは鍋とか箱と合体して恒温槽になるみたいな感じです。湯を吸って電熱で温めて吐き出すんですね。 これは Anova Precision Cooker です。ていうか Nomiku2 って別の低温調理器が本命だったんですが、クラウドがファンドってる製品なので開発が超絶遅れててこれはワンチャンポシャるまであるな、と思ったので急遽導入しました。これは120Vのやつで、もろもろ込みで28000円くらいです。普段から低温調理やりまくっている僕からすると神製品なので値段とかどうでもいい(よくない)ですが、そうでない人には全く必要のない物体です。温泉卵を大量生産
AWSでVPCを用いて作成したプライベートサブネットとSoftLayerのプライベートサブネットを、vyattaを用いてIPsec VPN接続する。 AWSのネットワークに対してSNAT/DNATを用いたりVPCルートテーブルの書き換えをせずとも、プライベートサブネットのIPアドレス同士がPeer-to-Peerで接続できるようにする。 SoftLayerのvyattaの設定 シンガポールDCとサンノゼDCに、以下のスペックのVirtual Serverを立ち上げる。 OS: Vyatta 6.6 Community Edision (64bi) CPU: 2.0GHz 1core RAM: 1GB RAM DC ホスト名 パブリックIP パブリックサブネット プライベートIP プライベートサブネット
ゴール nfs-server nfs-client というホスト名の Ubuntu 14.04 のサーバを2台用意し、nfs-server サーバに Network File System バージョン 4(以下 NFSv4) を構築、nfs-client サーバからマウントしてみる。 NFSv4 サーバを構築 まずは nfs-server に NFSv4 サーバを構築します。 必要なパッケージのインストール NFS サーバに必要な nfs-kernel-server パッケージをインストールします。 $ sudo apt-get install nfs-kernel-server nfs-kernel-server は NFSv3 にも対応しているようですが、今回は NFSv4 として利用します。 共有ディレクトリを作成 次に共有ディレクトリを作成します。 今回は /tmp/no_root
前回の記事では、以下の課題設定で、ユーザが30日後にデイリー・アクティブ・ユーザである確率(値域:0~1)を目的変数にとったロジスティック回帰モデルの係数を推計しました。 【正解データ】L回帰の目的変数 30日後の DAILY_ACTIVE_FLAG カラムの値 (1 or 0) 【説明変数】 ※各種調査の結果、手持ちの仮説は以下である。 (1) ある日のカード・ガチャ引いた合計回数(有償、無償合計)CARD_GACHA_COUNT (2) ある日の自己ステータス(体力、ユーザ中の相対順位、所属同盟・連合チーム全体の状況、保有カード数など)閲覧画面アクセス回数 STATUS_CHECK_COUNT (3) ある日に、連合仲間、同盟仲間とアイテム交換、激励アクション、メッセージ交換などを行った回数FRIEND_ACTION_COUTNT ロジスティック回帰を推計した結果、ユーザーアクティブ確
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ロードバランサー編) 〜今回、ロードバランサーは全面的に AWS の Elastic Load Balancing (ELB) を使用しました。 Web API を提供するシステムにはもともと ELB を使う予定だったのですが、静的ファイルの配信などは ClouldFront + S3 という構成でいこうと思っていました。 が、最終的には静的ファイルを配信するシステムも ELB + EC2 という構成になりました。 そのへんの経緯とか、AWS を使うときのシステムのフロント周りの負荷分散にはどういう選択肢があるのかとか、軽くまとめてみようと思います。 静的ファイルの配信には CloudFront を使ったほうがいいのかCloudFront は S3 と併用することで、静的なファイルの配信のことはほとんど考えなくていい、というくらい簡単
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く