AWS Summit Tokyo 2016 Developer Conference (2016/06/03)
タイトル: 『認証の課題とID連携の実装 �〜ハンズオン〜』 概要: FIDO、ID連携(OAuth・OpenID Connect)をはじめとした最近の技術をご紹介します。FIDOは端末とサーバー間でユーザー認証を安全に連携するための仕組みです。OpenID Connectはユーザーの認証と認可を連携するためのID連携の仕組みで、OAuth 2.0を拡張した仕様であり、HTTP通信やJSONなど基礎的なWeb技術によって構成されています。FIDOとID連携の技術を学んだ後、実習ではGolangを用いてWebアプリケーション上にOpenID Connectを実装します。実装の注意点とそのリスク、仕様に施されているセキュリティー対策についてハンズオンを行いながら解説します。 セキュリティ・キャンプ全国大会2019 専門講義 選択コース B4 認証の課題とID連携の実装 〜ハンズオン〜 Aug
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の2つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
新人研修担当の長田です。 今年も新人研修の締めとして社内ISUCONを行いました。 昨年はプログラミング基礎の講師をやったのですが、 今年はその実績を買われて(?)社内ISUCONの出題を担当することになりました。 過去のISUCON準備の様子を傍から見ていた身としては、 準備を始める前から「とにかく大変そうだ・・・」というイメージを持っていました。 問題を作りこむ以上、どうしてもISUCON当日ぎりぎりまでかかってしまうのでしょう。 ぎりぎりになるのはまあ準備する人が頑張ればいいとして、 ぎりぎりになった結果競技自体の進行が危ぶまれるのは避けたい! ということで、いくつか効率化という名の妥協策をとることにしました。 効率化できるところは? 毎回新規に出題するのはしんどい! 社内ISUCONは過去2回実施していますが、 どちらも新規に高速化対象のWebアプリケーションを作成していました。
アドテクスタジオのDynalystというチームで働いている黒崎 (@kuro_m88) です。 たまに社内で自作ドローンを飛ばしたりしています。 早いもので入社2年目になりました。つい先月まで新卒だったはずなのですが…(・・;) 今年も新卒の技術者が約60名入社し、新入社員全体の研修が終わり現在はエンジニアの技術研修が行われています。 今回はその環境構築で行ったことについて紹介しようと思います。 エンジニアの新卒研修の概要 今年の研修のゴールは「アーキテクチャをゼロから考え、実装できるようになる」というもので、研修課題は2つあります。 1つ目は現在まさに取り組んでもらっているのですが、2週間でミニブログシステムを3~4名のチームで制作してもらいます。 チームによってスキルセットが違うので、ネイティブアプリに特化するチームもいれば、バックエンドやインフラでいかにスケールしやすい構成にするか、
追記 (4/15) 現在は Let's Encrypt の証明書が利用できるようになっているようです。なので「https で Callback が受け取れない」と言う理由のためだけに Amazon API Gateway を使う必要も無くなりました。 LINE Bot API は Callback URL が https のみで、しかも Let's Encrypt や StartSSL と言った無料の証明書が使えない。どうにか安価で Bot を動かしたいとなると Heroku のようなドメインを指定しなければ Wildcard 証明書が割り当てられている PaaS を使うのが一般的でしょう。 しかし Heroku は外に抜ける IP アドレスがどんどん変わっていくので、 Bot API の IP Whitelist に登録することが出来ない。仕方無いので Heroku に rack-rev
Amazon RDS の MySQL から Amazon Aurora への移行は本当に簡単でした。本番環境を止めずに移行できることも分かったので、今後は順次移行し Amazon Aurora に一本化する予定です。 MySQL から Amazon Aurora に移行して、必要な性能も十分に得られています。今後 1,000 万ユーザーに増えたとしても、今のところなんら心配はありません。 株式会社 Zaim は、個人向け家計簿アプリケーション「Zaim」を提供する企業です。Zaim には iOS、Android およびブラウザで利用する Web 版があり、さらに Windows ストアから Windows 10 や Windows 10 Mobile で動くアプリケーションも提供されています。サービスではレシートなどをスマートフォンのカメラで撮影するだけで簡単にお金の利用が記録でき、紙の家
AWS SESは安価で簡単にメールの送信/受信トリガーが実現できるサービスです。AWSを使っているサービスの場合、けっこう使うことになると思います。が、ハマりどころや注意すべき所があるため、サービスの特性を理解して使ったほうが良いと思い、まとめてみました。 やること SESの制限解除申請をする DKIMに対応する/逆にSPFは対応しなくてOK バウンスと苦情の対応をSNS/SQSなどを使い自動化する 25番ポートは使用せず、465/587を使用する 配信メトリクスを監視する SESの制限解除申請 新規AWSアカウントの場合、SESはサンドボックスモードになる サンドボックスモードだと、検証済みEmail/ドメイン宛にしか送信できない 24時間あたり200通までの送信制限 / 1秒あたり1メッセージの受信制限 サンドボックスモードを解除するには申請する 制限はリージョン毎に行われる 詳しくは
はじめに AWSチームのすずきです。 今月(2015年10月)よりAWS東京リージョンで利用可能となった、RDS for Amazon Aurora。 とあるサイトのCMS(WordPress)のバックエンドDBとして稼働していたRDS(mysql)を移行し、 Amazon Auroraの性能の一端を確認できる機会がありましたので、紹介させて頂きます。 概要 RDSのスナップショットより、スナップショットの移行(migrate)を実施しました。 ElasticBeanstalkの機能(クローン、DNSスイッチ)を利用して、RDS(Aurora)参照環境の構築と切替を実施しました。 DBの最終同期として、mysqldumpコマンドによるエクスポート、インポートを行いました。 システム概要図 移行手順 スナップショットの復元 AWSコンソール、RDSのスナップショット画面より復元対象とするRD
たまに呟いていましたが、『Amazon Web Services パターン別構築・運用ガイド』に続くAWSの第二弾として、『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』という本を書きました。今回も、所属している会社であるNRIネットコム株式会社の同僚たちと書いています。そして今回の本は、主にアプリケーション・エンジニアを想定して書いています。何とEC2の使い方が一切でてきません。 Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく 作者: NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴出版社/メーカー: SBクリエイティブ発売日: 2016/04/20メディア: 単行本この商品を含むブログを見る 本を書いた理由 前回の『Amazon Web Ser
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
by @appwatcher 以前下記で書かせていただいた goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 ですが、上から下まですべてを担当して個々の技術をすべてやった経験自体も勉強になったのですが、 どうして、そのような技術選択をしたか?という点が自分でも振り返ってみて学ぶ点がありました。 それぞれ良し悪しがあったので何かしらの参考になればと思い、それ以後の技術変遷や取捨選択を踏まえて、振り返ってみたいと思います。 なにかしらの参考になれば。 ちなみに未だに一人です。 今回の技術選択をした時の基準や自分なりの戦略 スピード重視。これは今回に限らず自分自身の戦略です。基本通常の人の3倍のスピードでやる気概でやってます。 ユーザーグロース重視。これはサービス立ち上げからやるので当然。 コスト重視。今回フリーになってコストまできちんと意識するようにな
Docker 社のユースケースでもあげられているように、CI/CD で Docker を使うというのは、プロダクションシステム以外で Docker の特性を活用できる良い場所だと考えています。ヌーラボではBacklog でのプルリクエストの提供以降、CI のジョブの実行のために Docker を利用しています。ここではその運用から学んだ5つの Tips を紹介したいと思います。 ヌーラボの CI 環境の全体図 これがヌーラボの CI 環境の全体図です。 CI には Jenkins を利用しており、Jenkins のジョブのトリガーとなるのは左側の Backlog や Typetalk です。実際には Jenkins Backlog Plugin や Jenkins Typetalk Plugin を利用してジョブを処理しています。これらのプラグインの詳細については本ブログ末に参照先をのせて
AWSアカウントを作成したら最初にやっておきたいことをまとめてみた。 あわせて読みたい 本記事の内容を含めた最新の手順は、下記の書籍にまとまっている。 クラウド破産を回避するAWS実践ガイド AWSアカウント(ルートアカウント)の保護 AWSアカウントが乗っ取られると詰むので、真っ先にセキュリティを強化する。 AWSアカウントへ二段階認証を導入 AWSアカウントでのログインは、AWSアカウント作成時のメールアドレス・パスワードだけでできてしまう。心許ないにもほどがあるので、まずは二段階認証を設定しよう。 IAMのページを開く https://console.aws.amazon.com/iam/home 「ルートアカウントのMFAを有効化」を選択して、「MFAの管理」ボタンをクリック 「仮想MFAデバイス」にチェックが入っていることを確認し、「次のステップ」ボタンをクリック 注意書きを読ん
今日はAmazonEC2を使ってコンピュータに24時間FX自動売買させる方法をご紹介します。 これによって寝ている間も機械がトレードを続け、うまくいけば左うちわで暮らしていけるかもしれません。 FXはやったことあるけど結局負けて退場した、システムトレード(自動売買)は聞いたことあるけどコンピュータを24時間稼働させるのが出来なくて諦めた、という方いませんか? そんな方のご参考になればと思います。 まず、必要な準備として証券会社とAmazonEC2のアカウントが必要になります。 ①メタトレーダー4が使えるFX会社のアカウント 私はFXDDという海外の業者ですが日本の業者も多くあります zai.diamond.jp ②AmazonAWSのアカウント aws.amazon.com さて、お金持ちへの準備が整ったところで早速設定をしていきましょう。 最初にAmazonEC2で24時間稼働させる方法
AWS 上の DNS 環境である Amazon Route 53 に、 DNS を移してみました。これは、その記録。 Amazon Route 53 http://aws.amazon.com/jp/route53/ 一般的に DNS といえば、Linux 系の方であれば BIND や unbound を思い出される方が多いのではないでしょうか。BIND であれば、named.conf にゾーンのエントリを追加したり、セカンダリDNSサーバを登録したりと、ゾーン転送したり。…これが手作業だと、結構面倒だったりしますよね。ウッカリ Serial を更新し忘れて、一日中延々と悩んだり、レコードに「.」をつけ忘れて www.example.jp.example.jp のような情報ががが、とか。 一方、Amazon Route 53 は、ブラウザで画面をポチポチするだけでドメインを管理出来てしまう
AWSを使い始めて約一年が経過したので、この一年を振り返ってみて、最初から知ってた方が良かったな〜と思ったポイントをピックアップしてみました。 IAMロールはName変えられないし付け替えもできない件勢いだけで作ったIAMロールを付与して意気揚々と運用開始!数ヶ月後に付け替えできない事に気付いて、ec2ctrlとかいかにもEC2インスタンスをコントロールするためのロールなのに、なぜかS3の全権限付与してたり、もはや名前から予測できない事態になってしまったという話。 まぁ、別にオオゴトでは無いんですけどね。インスタンス作り直せば付け替えできるし、新しいロール作ってインスタンス作り直せばいいだけの話です。やるかやらないか。 やりませんけど! VPCでVPN接続はリージョン毎に1つしか設定できなかった件IDC側のグローバルIPが複数用意できない前提ですが、IDCとAWS(VPC)間でのVPN接続
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照/更新クエリを実行しています デ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く