まめ畑スマートフォン用の表示で見るまめ畑ゆるゆると書いていきますこの広告は、90日以上更新していないブログに表示しています。#1に参加してきました。http://connpass.com/event/11019/セキュリティというところで、現場のシビアな実情が垣間見えて非常に参考になりました。セキュリティを日々どう守るかとかAWS上でどう安全な環境を作るかという視点は今後もっと大切になると感じました。様々な要望やシステムを守るためにAWSにまだまだ足りない物事や、AWSの勉強会では普段聞けない話が続々とでてかなりハイレベルな勉強会でした!要望などは本当に伝えたいと思います!キーワードは、認証情報の管理の仕方、しやすさだと感じました。基本的な考え方はAWSだからというところが少ないもちろん、ミラーポートやIPS/IDSなど出来ない事もあるAWSは全リソースがAPIで提供されているAPIを守らないといけないEC2やRouteテーブルなどを全削除やデータの引き出しなどS3やEBSのSSEはAPIにアクセスされない事が前提。さんが上海から来日されたということで開催されました。JSONで設定書いて、それをVyOSのconfigに変換するスクリプトを書いた。L2TPv3にも対応している。するパッチを公開予定。ebtablesのstormcontrolとか追加。ebtableshは開発は止まっていてnftablesmacアドレスを通すか、ライフタイムやマルチキャスト、バースとしたときにどれだけ通すかを設定。独自拡張が入っているためOSSにしにくい。VTEPは、arp→multicast→larningで、どのMACがどのVTEPの下にいるか学習。NICのBuffer溢れが発生した。masqueradeでは大事メモリ消費するので注意conntrack周りのtimeoutは短くしまくったServerいっぱいあるので無慈悲に短くマイクロバーストトラフィックはnono-secでの出来事。10万セッションのNATでも動く単位時間あたりのセッション数は?TCPreplayを使った20,000ppsあたりまではエラーなし。ファイルの書き換えと再送信ユーティリティまとめ今回も深いお話で非常に勉強になりました。VyOSをプロダクションでヘビーに使っている事例お増えてきて機能もドシドシ追加されているので、試してみるのはいかがでしょうか。触っていないので触ってみなければ。Tlaks#3に参加してきました。Zusaar2回目までは主催していたのですが、今回から主催をCookpadの星君に移して初めての開催でしたが、過去を超えてくる濃い・本気の内容ですごく良かったです。オンプレ環境で大容量・高トラフィックな配信環境を作った時の話しとAWSで作った際の話。オンプレ環境で実現する場合はクリアしなければいけない課題をAWSのサービスでどうクリアしたかという話でした。Transcoderの実用事例を聞けた貴重な機会でした。移行記オンプレ環境からAWSに完全移行した際のお話で、オンプレで使っていたものをAWSに移行する際にどう変えて移行を実施したか、非常に勉強になる話でした。AWSは完全にオンプレで実現出来ることをそのまま実現することは出来ないので、AWSベースな考えやシステム設計にしていくことになるのですが、何を使って何を使わないか、その判断の基準など非常に勉強になりました。VPCを使わなかった話など今後参考になる方多いのではないでしょうか。mackerelはAWSに親和性高いですね。(仮)本舗初公開のDynamoDBのパーティショニングの話を公開しました。DynamoDBはProvisioningされたスループットをどうパーティションで割り振るかや、Unitを下げた時にどういう動作をするか今まで公開されませんでしたが、今回ついに公開されました。スループットを下げた際に、パーティションのマージは行われず、ホットパーテションの問題が起こる可能性がありますが、こちらはスループット設計時にベースunitを指定し、バースト分に関しては今まで通りスループット向上をするという方法で問題無いかと思います。この辺の話が外で公開出来るようになったことで、DynamoDBのスループット設計やスループット増減戦略が行い易くなったのではないでしょうか。詳細は今後聞いていただければお手伝い出来るところかと。LibraryもPython版がでたり進化してますね。参考にならないAWSに関するブログの書き方の話AWSのサービスUpdateに追従してBlogを書いて頂いている、裏話。今まで語られることがなかったので新鮮でした。VPCがリリースされて久しいですが、アクセス制御をどうするか、皆さん気になっているところだと思いますが参考になったのではないでしょうか。アクセス制限はAWSのサービスでもそれぞれ異なる方法があり、出来ること出来ないことなどもあるので難しいのですが、きちんと設計して安心・安全な構成を。BigQueryこちらはよく聞かれる質問ですが、LTでも話がでた、しっかりテーブル設計をしてクエリをしっかり設計してクエリを投げるのであれば、Redshift。Redshiftおじさんが必要。なく、そこまで複雑でないクエリならBQと、しっかりと要点抑えられたLTでした。内容的には同意で、ストリームアップデートなども考えると性能特性などをみて適材適所ですね。気軽にビックデータ系のサービスが使えるようになったのはすごいことだなぁと改めて思いました。POODLEPOODLE対応の話。SSLv3を切るという対応がいいと言われていますが、実環境での難しさとAWSで対応を探った話。CloudFrontとELBも実は対応完了しております。いうところで耳が痛い話でしたが、参考になるところが多かったのではないでしょうか。Capacityを使うことで値段が下がるかと。CapacityでUpfront入れて月30万円位になるでしょうか。(http://aws.amazon.com/jp/dynamodb/pricing/)そして、DynamoDBとredis/fluentdの合わせ技のRedy、書き込みに遅延は出てしまいますが、redisを同一VPC内に置くことでhit時の読み込みLatency軽減期待できそうです。Genkiまとめ今まで以上に深い話や濃い話、AWSのdeepな話が会が終わった後も聞けたので個人的には非常に満足でした。個人的にも勉強になる話が多く、参考になりました。cognito最近、AWSのサービスも少し様変わりしてきて、インフラレイヤーから、アプリレイヤーまで幅広くサービスが出てきています。SDKも充実してきていて、デバイスやブラウザから直接AWSサービスにアクセスして、S3にデータをUploadしたり、DynamoDBにデータを入れたり、Kinesisにログを流し込んだりなどなど今までサーバをかえして行っていた処理が突き詰めればサーバレスで行えるようになってきました。データを受け取って整形など複雑な処理を行いたいという場合には今まで通りAPIサーバなりを用意する方法になるかと思います。ここで一つ問題になるのが、認証周りかと思います。ブラウザやデバイスから直接S3にデータをUploadしたり読み出したりするアプリがあった場合、S3にアクセスするための認証情報をセットする必要があります。Brokerを用意して一時的なキーを払い出すという方法がありました。Cognitoを使うことで簡単に実装出来ます。Congnitoは認証だけでなく、デバイス間でのデータ同期なども備えているため是非試してみてはいかがでしょうか。};こんなかんじで、FBのアカウントと連携して作れます。このへんは今回の本題では無いので、詳細は省略します。画像なり動画なり大きなデータをブラウザから直接S3にUploadしたいという場合、S3に対してCORSの設定をすることになりますが、一点だけ注意点があります。SDK経由でアクセスすると、CORSが効いていないよなエラーが表示されて、リクエストが失敗します。preflight.見てわかると通り、S3のエンドポイントのリダイレクト(s3共有ぽいURLからリージョンスペシフィックなURL)が起こっています。このリダイレクト先がCORSを引き継いでいないため失敗しています。これはしばらくまつとリダイレクトされなくなり、CORSも効きアクセスが成功します。新規Bucketでうまくリクエストがいかないなぁという時に確認してみてはいかがでしょうか。Configurationで設定します。AllowedMethodは許可するものを選んでください。PolicyでこのFacebookのこのユーザIDの人は自分のバケットだけ操作出来るというIAMで使える変数もあるのでご活用ください。familyでT2シリーズが出ました。Purposeにカテゴリも変更されています。リリースは以下の記事http://aws.amazon.com/blogs/aws/low-cost-burstable-ec2-instances/http://aws.typepad.com/aws_japan/2014/07/low-cost-burstable-ec2-instances.html置き換えはt1.microをt2.microへm1.smallをt2.smallへm1.mediumをt2.mediumへという感じです。特徴としては、CPU(ECU)がバーストするということです。リリースにも書かれている通りのアルゴリズムでバーストします。普段は負荷が少ないけど、ある時間のみCPUをおもいっきり使用する様なケースに置いて有用なインスタンスだと思います。(gp2)とあわせることで、起動時の速度EBSで、処理の速度向上をt2のバーストで行なうことで、起動や処理速度の向上が期待できます。Benchをしてみました。実行中はバーストが常に起こる状態です。結果をわかりやすくするため、microを使いました。UsageCloudWatchで見ることができます。t2.microです。Creditを使いきってみた見て分かる通り、バースト中でCPUを100%使える状態から、クレジットが減少してきてt2.microのベースラインである10%に綺麗にキャップされていく様子が見れると思います。stealという状態になりました。実際に使えるのが10%ということですね。benchが完走しない事もありました。クレジットは1分ごとに各インスタンスタイプ毎に決められた割合で復活していきますので、バーストを必要としない状態になったら徐々に回復していきます。hours)まで貯めることが出来ます。Purposeにカテゴライズされていることも注目だと思っています。普段はバーストしないが、バッチの瞬間だけおもいっきりCPU使いたいとか、ある処理の瞬間だけCPUをフルに使いたいという場合にちょうど良いのではないでしょうか。お財布にやさしい感じだと思っています。今回はt2.microを使ったため極端な性能劣化が見受けられましたが、t2.small/mediumなどワークロードにあったインスタンスを要件に合わせて使うことが大事だと思います。2014のセッションとして、これで最強のAWSにというセッションをやりました。まとめて頂いています。各セッションの発表資料はタイムテーブルからリンクがあります。このセッションは、普段AWSを使っている方々をお呼びして、使っているからこそわかるAWSのイマイチなところ、イケてるところ、バッドノウハウ、こうしたら・こうなったらもっと良くなるのにという話をして頂きました。SAの大谷さんにもご参加頂き、直接要望や実際のところどうやったらいいのさ?という事を直接伝える場があったらなと思い企画しました。(企画の大本は実はre:Invent2013開催中のラスベガスの会場にて生まれました。15AWSのイベントでざっくざっく切り込んで行くスタイルをやるのは3回目くらいですが、いつ突っ込まれるか毎回ヒヤヒヤものです。Infrastructureのパネルが行われており、セッションにどのくらい人が入ってくるか不安でしたが、実際始まってみると、常時立ち見が出る状態で、終了後やTwitterなどの反応・会場での人気投票でもかなり良い評価をいただけていたようでした。これは本当に発表していただいた3名とMilesさん・大谷さんのおかげと思っています。さん発表で印象だったのは、オンプレとAWSを透過的に扱えるツールがあること。オンプレ・AWSを同じように扱えるというのはとても大事なことだと思っていて、AWSを使うとなっても運用方法が大きく変わってしまうと、それだけでも結構なコストになってしまうと思います。MHAに比べるとRDSのフェイルオーバーはまだまだ時間がかかるというのは自分も同じ悩みを持っていて、Milesさんが言うには今はもっと時間短縮されているとのことですが、それでも数分のオーダー。re:InventでもRDSチームとMTGする機会があったのですが、そこでも切実にお願いしておいた案件です。AutoScalingやRDS、CloudWatchなどオンプレと同じ構成で自前で運用しなくてもフルマネージドサービスとしてAWSには存在しますが、ブラックボックなため障害時の切り分けやAWSならではの制約・制限に引っかかり実はすんなり移行できない併用しにくい部分というのが存在します。既存の環境でツールなどが作りこまれてると、AWSに移行したとしても、自前でコントロールしたほうが案外運用しやすかったりするものです。発表を通して、同じ悩みを抱えてる...と思っていました。dieのフリークアウトさんの発表。Groupが要件を満たせそうな感じがしますが、HPC向けインスタンスなどのハイスペックインスタンスしか使えないです。AWS内部のlatencyのゆらぎもここまでシビアな要件になるとかなり影響がでるのだろうなと聞いていました。後は、AWSの管理周りの話。tableやRoute53などいじる場合やEC2インスタンスを起動するだけでもわかりにくいオプションを使わないといけない。AWSはインフラをコードで管理できるが、Sandboxなどのテスト環境が無いのが辛いという話は会場やTwitterでも共感の声が多かったように思います。Consoleの操作を記録して、コードなどにしてくれる機能。これは確かに欲しい...Sandboxに関しては、Eucalyptusが使えるとMilesさんからの回答がありました。runだけでなく、テストしやすい方法があると良いなと思っています。さんサイト毎に1アカウント1VPCという使い方。これはお金周りなどなどの事情によるものだそうで。今70VPCを管理しているという構成図を見てかなり驚きました...そして、それぞれのVPCがオンプレや監視を行ってるVPCと通信していて、通信にはVyattaにてVPN、ルーティングやNATが行われているという、そしてVPCも頻繁に増えたり消えたりと頭蕩けそうな感じでした...AWS公式にVPCのIGWがVPC間ルーティングをサポートしてくれるとスッキリとした感じになると思うのは凄く同意です。後、事前アンケートでも多かった、サブネットのリサイズ。最初スモールスタートやオンプレとNW周りを合わせるために小さくサブネットを切ってしまうと、インスタンスが増えてきたり、ELBが増えると(ELBは5-6個IPアドレスを消費します)IPアドレスが足りなくなってしまい、リサイズが出来ないので、VPCなりサブネット作りなおして引っ越しとなってしまします。技術的に難しいのはわかるのですが、欲しい機能の1つです。最初からどかんと大きくサブネットを切るというのも手なのですが、そうするとサブネット数が少なくなるのでこちらも中々悩ましいところです。DAYSを通して、AWSは本当に様々な業界や形態で使われているというのを改めて実感しました。それぞれの要求に答えていくことは非常に難しいことだとは思いますが、その中でも共通して共感できる部分というのも少なくは無く、その部分に関して直接中の人にフィードバックしてお伝え出来てよかったかなと思っています。いう場面が何回もあったり、それいいね!ということもありました。それぞれの質問にも丁寧に答えて頂き、セッション終了後も色々話して頂きました。AWSを使い始めよう・使い始めたばかりという方には、こういうこともあるのか、とか、普段バリバリ使ってる方には、それやっぱありますよねーみたいな感じ思っていただければ嬉しいところです。事前に行った、バッドノウハウアンケートでも予想以上の回答があり、いくつかは直接答えていただけました。こちらもアンケートにご協力いただいた方々ありがとうございます!ちなみに、事前アンケートで一番多かったのは、EBSの性能周りで、容量を大きく(500GB以上)そして、IOPSも高く設定して、事前に全領域にddなどで書き込んでおかないと性能が...とかもう少し1本でIOPS出したいというものでした。bandやRDMA使いたいなどもありました。意外とバッドノウハウ集まってます...監視についても色々ありましたが、Milesさん的にはNagiosやzabbixなどと組み合わせて、CloudWatchを使って、CloudWatchはAWS内部で取得しているメトリクスを見るのに使うのに適してるとのこと。監視も適材適所ですね。AutoScalingに関しては、CloudWatchに頼らず、自前のスクリプトでMax/Minのキャパシティを調整するのがいいんじゃないかなぁとのことでした。カジュアル!このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流してみるのが確実かつ影響を確認しやすいと思います。これは結構難しかったりします。実際に発行されるクエリを集めるのが特に面倒。logを有効にしてDB側で記録してしまうというのも手なのですがパフォーマンスにも影響が出てしまう可能性があるのと、アプリケーション規模やアクセス量が大きくなるとログ量がすさまじいことになってしまいかねません。(収集するサーバへのリクエスト振り分け率を落としても。)また、せっかく集めてもアプリケーションの機能追加などは検証中も随時行われているため、新規発行クエリをまた集めないといけません。これはカジュアルじゃないですね。実際に移行してみた先日とある大きなサービスの大きめのDBバージョンアップ(メジャーバージョン2アップ)とパラメータ調整を行った際に実際に使用した方法をご紹介します。(5.6へじゃないですよ...)まず、DBのバージョンアップを行う場合以下の様な方法で行うと思います。左側が旧環境、右が移行先です。masterをSlaveとして、更にその下にSlaveをぶら下げます。(新Master達はバックアップやSnapshotから複製していきます。dumpからimportした場合でない場合は、mysql_upgradeを忘れずに)切替時は、一旦メンテナンスモードなどに入れて、レプリケーションを切り、アプリケーションの接続先を変更します。これで完了となります。Kageメンテナンス前の検証やパフォーマンス・チューニングではKageを使用しました。Deckを見ていただくとわかりやすいですが、リクエストを複製して、2つのバックエンドサーバにリクエストを送り、レスポンスのdiffを取ったり、新アプリケーションのパフォーマンス計測を気軽に行うことが出来ます。ユーザさんへのレスポンスはオリジナルサーバからのものが返却されるため、カジュアルにテストを行うことが出来ます。今回は、以下の様な構成でテストを行いました(赤線はバックアップ用の設定経路です)本番環境のproxyの下にKageサーバを配置し、その下に旧DB群につながっているアプリケーションサーバと、新DB群に繋がるアプリケーションサーバを配置しました。新旧DBはレプリケーションされていますが、書き込みテスト時にレプリケーションエラーが発生することもあるので、最初はSELECTが殆どのページを先にテストしてしまい、その後全ページをテストするという方針で行いました。新Masterへ書き込みが起こるのでレプリケーションエラーも発生しますが、このテストでは、アプリケーションへの影響・パフォーマンス・オプティマイザまわりを見たいため、こちらは基本的に無視をしてレプリケーションを行うようにしました。このテストでは、Kageサーバのパフォーマンスによっては全てのリクエストをさばけないため、Kageサーバへのリクエスト振り分け率は下げてあります。そのためDBへの負荷は既存の本番サーバよりも低くなるため、負荷テストなどは別途行います。そのためのSQLリストを取得するためにもこの構成は有用で、テスト用のサーバからはレスポンスがユーザさんへ返却されないため、SQLのログをアプリケーションサーバで出すように気軽に出来ます。DBのパラメータ・チューニングもカジュアルに出来ます。この構成では検証用アプリケーションサーバもデプロイターゲットにしておくことで、新機能などで新規発行されるSQLもリアルタイムに受け付けることが出来るため、常に最新の状態を検証でき、サイトの動線やユーザさんの行動もシュミレーションではなく実際のものが取れるため、推測ではない実際のトランザクションをで検証が行えます。ご存知の方も多いと思いますが、もし、新DBが5.6でGTIDをONにするぜ!!というナウいヤング方は、この構成ではONに出来ません。positionをONにします。endendこの様な感じで、2つのバックエンドサーバのレスポンスを比較したりしています。newdb-appではログレベルも変えてあり、負荷試験用にSQLログを出力させています。compareのところで、bodyだけ取り出しレスポンスを比較したり、速度を見たりします。その辺はお好みで色々いじれます。MySQLサーバのエラーログも忘れずに見ましょうね!まとめMySQLのバージョンアップは色々と気を使う部分が多く、アプリケーションの開発速度が速いとさらに影響範囲を調べるのが手間になってしまいます。Kageを使うことで、リアルタイムにクエリ状況を確認出来るため少しは手間が減るんじゃないでしょうか?バージョンアップ以外にも、チューニングなどにも活用できます。Tumblr広告を非表示にするもっと読むコメントを書く次のページプロフィールid:con_mame技術ネタを主に書いていきます。こちらのBlogは個人の意見で会社とは関係ありません。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。