プログラマでありたい

おっさんになっても、プログラマでありつづけたい

夏のJAWS-UG 三都物語 2014でCDP道場に入門してきました

f:id:dkfj:20140708075033j:plain
(西島さん、撮影の写真)


 7/5に開催された夏のJAWS-UG 三都物語 2014で、もう1つのネタです。一度はやってみたいと思っていた、CDP道場に初めて参加してきました。もともとスタッフとしての参加でしたが、JAWS−UG沖縄の西島さんの尽力のお陰で、当日まで何もせず手ぶらで参加してチームリーダするだけで済みました。ありがとうございます&役に立たずにすいません。

CDP道場について



 お題とチームの回答については、今後も使い回しをする可能性があるので省略します。(正直言うと、お題のURLも結果のアーキテクチャの写真も残しておくのを忘れてました。)私のチームには、AWSを普段使いしている人はいなかったものの、オンプレミスでのアーキテクチャ設計が豊富な人がいたので、やりたいことをAWSでどう実現するかを翻訳するだけで、ほぼアーキテクチャが完成しました。その点、非常にチームに恵まれていました。チームメンバーの皆さん、ありがとうございました。
 ちなみに初めて参加だったのですが、経験者としてCDP道場に参加するのは、どこまで引っ張って良いか非常に悩ましいです。今回の場合は、アーキテクティングの時間が、1時間と非常に短かかったです。AWSに関しては初心者の方が殆どなので、調べながらではタイムアウトになることは目に見えていました。となると、AWS難しいという印象だけ残して帰っていくことになるかもしれません。一方で、私が主体となってやると、恐らく置いてけぼり感が満載で、面白くないでしょう。そう言った点で、非常にさじ加減が難しかったです。最後の方は、時間がなくてちょっと答えを出し過ぎてしまいました。
 初心者向きであれば、AWSの各サービスのチートシートを作って、30分で説明して2時間くらいあれやこれやが出来ればなぁと思いますが、全体の尺が非常に長くなるので中々難しいですね。アーキテクチャの選択ごとに、関係するサービスの説明をしていたのですが、短い時間でどこまで伝えられたか自信がないです。

セッションストアと外接について



 最後に、AWSの堀内さんを始めJAWSUGのコアメンバーの猛者に色々とツッコミを頂きました。印象に残ったのが2点。1つ目は、セッションストアにElastiCacheという選択に対して、MultiAZをどう対応させるかという指摘です。これは、ElastiCacheのMemcachedがAZを跨いでCache Clusterを構築できないことに起因します。セッションストアにMemcachedを使うというアイデアに、それならElastiCacheがあるよという脊髄反射をして、その辺りの考慮を完全に失念していました。
 会場でのディスカッションでは、DynamoDBをセッションストアに使ってはというアイデアなどが出てきました。自分ならどうするかなという所を、改めて考えてみました。まず基本方針としては、以下3点です。

  • セッションストアは、必ずアプリケーション・サーバから別だしにする(ローカルのサーバのメモリにセッションを格納しない)
  • レプリケーション機能は、過信しない(セッション用途で使うのであれば、準リアルの同期(≒レプリケーション)では不足)
  • ELBのスティッキー設定は、補助的に使う(例え同じサーバに割り振られなくても、セッションがある状態にする)

 上記考慮の上で、セッションストアに何を使うかの優先順位です。

  1. アプリケーションがAPIの類であれば、ステートレスにしてセッションを使わない
  2. ミドルウェア/フレームワークで、セッションストアとしてDynamoDBを利用できるのであれば、それを利用する
  3. EC2上にKyotoCabinetを構築して、マルチマスタ構成にする。ただし、アプリ側からはマスタスレイブ構成として、どちらかのAZを優先して接続するようにする。(マスタに接続できない場合は、アプリ側でスレイブに倒す)
  4. 選択肢がない場合は、DBをセッションストアとして利用する
  5. ELBの方でスティッキー設定をした上で、ミドルウェアのセッションのレプリケーション機能を使う
  6. セキュリティ上問題にならないのであれば、署名付きでCooki Storeも検討する

 正直、使うミドルウェアやフレームワーク次第なのですが、みんなどうしているのでしょうか?各言語・フレームワークごとのベストプラクティスをまとめてみたいものですね。(1年ほど前に、考えていました。)
アプリケーション・サーバのセッションの保存先の話


 2点目の指摘事項は、外部システムの接続をサーバから直接で良いのかという点です。要は、外部のシステムと密結合にする危険性についてです。この指摘については、100%同意です。基本的にはSQSをかまして、システム間を疎結合にします。場合によっては、SWFが使えないか考えます。この辺りは、密結合の危険性とSQS,SWFが何ぞやという説明が必要なので、時間切れになってしまいました。

感想



 やってみて解ったのですが、CDP道場は上手くやればどんなレベルの人にも勉強になります。初心者の人は、中級者以上の人がどう考えるのか。また中上級者の人は、AWSやJAWSUGのコアメンバの指摘やディスカッションを通して、別の見方に触れられます。中々、効率的な学習の仕方だと思うので、機会があれば臆せずに積極的に参加すると良いですね。
 ちなみに個人的には、悩む機会が多い共有ストレージやコンテンツ同期の方法でCDP道場やって、色々なパターンを見てみたいと思いました。


See Also:
アプリケーション・サーバのセッションの保存先の話
アプリケーション・サーバのセッションの保存先の話


参照:
CDP道場とは?その1 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その2 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その3 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その4 | 夏のJAWS-UG 三都物語 2014


Amazon Web Servicesクラウドデザインパターン設計ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド