MyCSS

2012/12/17

テレワーク関連で登壇します、的なお知らせ はてなブックマークに追加

テレワーク1周年記念シリーズの第2回目の記事にて、「次のエントリに続く」と書いておきながら第3回目がさっぱり出ないデルデル詐欺な今日この頃ですが、皆様いかがお過ごしでしょうか?

さて、今年もあと半月を残すだけ、来年の話をすると鬼が笑うと言いますが、そんな事言っても若い人にはサッパリ通じず、ジェネレーションギャップに苦しむ事になりますから自重しておきますが、来年1月に東京と札幌で「テレワーク」に関してお話しする機会を頂きましたので、お知らせしておきたいと思います。

エンジニアサポートCROSS 2013
2013年1月18日(金)ベルサール新宿グランドにて行われる、@nifty エンジニアサポート主催のイベント、エンジニアサポートCROSS 2013にて、エッジの聞いたテッキーなセッション満載の中、

「クラウドな働き方 x 介護 〜来るべき育児と介護をどうITの力で乗り越えるか!?〜」

という、異色?のセッションで登壇します。

福岡の小室(@ayakomuro)さん、金沢の相羽さん(@aibax)、東京の竹下さん(@dynakou)、札幌の私(@dateofrock)の4名で、実際に「クラウドな働き方」で「育児」や「介護」を実践している皆さんと一緒に登壇します。

どんな話になるのか、クラウドな働き方、テレワークはこれからのワークスタイルの一つになりうるのか?そういった漠然とした疑問をお持ちの貴方と貴女、お待ちしておりますw そして、会場の皆さんと一緒にこういった問題について議論出来たら大変嬉しいです!

もちろん、このCROSSというイベント自体が相当楽しそうなので、私も一参加者として純粋に楽しみたいと思います。

LOCAL DEVELOPER DAY'13 / Infra & Security

2013/1/26(土) 札幌市生涯学習総合センター ちえりあ 6F 講堂 にて開催される、 LOCAL DEVELOPER DAY'13 / Infra & Security というイベントにて、

「エンジニアのお仕事 実際の話」

というセッションで、AWSを活用したテレワークに関してお話しようかと考えています。

北海道には、技術系コミュニティの活動を支援している一般社団法人LOCALという団体があります。有名どころではオープンソースカンファレンスHokkaidoなんかを運営されているのですが、今回のイベントでは実際に現場に立っている人に話をしてもらいたい、と言う有り難いオファーを頂戴致しました。そこで、

東京の
中小企業の
印刷会社の
ソフトウェアエンジニアが
AWSを全面的に活用して
札幌でリモート勤務している
という、一見わかりにくい実際のケース(つまり私w)をご紹介出来れば、と思います。

いずれにしても、まずは「テレワーク」という勤務スタイルの実際をちょっとでも知って頂ければありがたいですし、そもそも北海道(特に札幌)はこう言ったワークスタイルの受け皿として有望な地域だと言う事を実感しています。そして、クラウドはエンジニアの生き方を変える事が出来る強力なイノベーションだとも思っています。

ですので、ブログだけじゃなく、こういったリアルな場があれば微力ながらも出て行こうと思いますので、機会がありましたら是非、足をお運びくださいませ。

2012/12/02

Amazon SWF Flow Frameworkのエラー処理について はてなブックマークに追加

AWS Advent Calendar 2日目担当の@dateofrockです。初日は横浜支部の吉田さんが書いておられます。なんでもラスベガスで開催されたAWSのグローバルイベントに参加された後、シアトルのホテルから記事をアップしたとか。うらやましー。

こちらはすっかり冬景色の札幌からお送り致しますww


どうでも良い前フリ
http://www.flickr.com/photos/trasroid/3108074700/
えーと、全然関係ないですけど、サンタクロースってトナカイが引っ張るそりに乗って来ますよね。しかも、煙突から入ってきますよね。
クリスマスの季節には雪で真っ白な札幌に生まれ育った自分にとって、このサンタクロースはリアルに感じられておりました。
クリスマスが近づいても雪が少なかったりすると、そりが滑らないんじゃないか?とマジで心配したり、自宅の煙突はきちんと掃除されているか気になったり...(笑)

神奈川に住んで、東京で仕事を20年やってきましたけど、関東のクリスマスって雪も降らないし空っ風ピュ〜だから、子供達は皆どう思っているのか、長年の疑問でしたww

うちの息子もいったいどう思っていたのか・・?彼が大人になったら聞いてみたいと思います(笑)


ネタはSWFです
さて、このAWS Advent Calendarは執筆陣が豪華なので、このメンツの中でいったい何を書けば良いのやら、結構悩みました。JAWS-UG札幌支部から代表?として書くからには、あまり下手な事はかけないし、さらに日程をAWSの荒木さんに譲って頂いたので、これはガッツリ「ディープな話題」で行くしか無いとwww

先日のラスベガスで日本初のCDP(クラウドデザインパターン)を世界に対して発信されたAWSの片山さんが、すでにスベってるタイトルでSWFを取り上げるらしいのですが、楽しく正確な記事はそちらを見て頂くとして、私は以前書いたFlow Frameworkをさらに掘り下げることをやってみたいと思います。

なので、前回の記事を読んでいない方はそちらを先に読んでください!じゃないと、今から書く記事の意味が分からないと思いますwww

あと、コードはgithubに置いてありますので、そちらもどうぞ!

失敗を恐れるべからず
SWFで処理するワークフローはこのような感じでした。
  1. だれかがS3へ画像をアップロードする
  2. S3から画像をダウンロードする
  3. モノクロに変換する
  4. 処理完了をメールでお知らせする
これを見ると、危険な場所が沢山ありますよね。例えば、ファイルをアップロード・ダウンロードする訳ですから、ネットワーク障害などで失敗する可能性もあります。また、画像変換処理も危険な香りがしますよね。

ワークフローの途中で処理に失敗した場合、その先の処理は当然出来ないのできちんとワークフローを中断させる必要があります。
また、処理が失敗した事をログに書いたり、管理者にお知らせしたくなってますよね?

こういう面倒な事をスッキリ実現出来るクラスがFlow Frameworkに用意されています。では実際のコードを書いてみましょう。


話を簡単にする為に、S3からのアップロード、ダウンロードに失敗する事を想定してみます。もとのActivityのコードはこんな感じでした。 これらのメソッドに対して、きちんと例外をスローするように変更しましょう。


想定されるエラーを分析すべし!
もともとAWS SDKではAPIの呼び出しでエラーが発生した場合、AmazonClientExceptionのサブクラスが投げられます。これはRuntimeExceptionを継承したクラスなので、try/catch節を書かなくて済む、という利点がありますが、ついつい忘れがちなので注意が必要です。また、実装クラスの中ではローカルにテンポラリファイル作ったり、ストリームを読み書きしている部分があります。これもIOExceptionが投げられる可能性があります。

この二種類の例外は性質が全く異なるものですので、一緒くたにせずにきちんと分けて処理する事にします。その為に、オレオレExceptionを定義しておきます。(これが後で効いてきますよ!


この例外をスローするように、アクティビティの実装を改良してみましょう。



エラーは謙虚に受け止めた上で、雲になげてしまえ!
さて、WorkflowImplの方ですが、普通に考えたらスローされる例外をJavaのtry/catch/finally節で処理するでしょう。そのようなコードは一見問題なさそうに見えますが、忘れちゃならないのが「非同期実行される」という事実です。各アクティビティをわざわざメソッドに切り出して、@Asynchronousアノテーションを付けている事を忘れないでくださいw


SDKではTryCatchFinallyクラスが用意されています。実装のやり方は簡単。Javaのtry/catch/finally節を書くのと同じ要領です。


doCatch()の中では、ログを書いて、管理者にメールを送って、例外を再スローしています。
doFinally()の中では今回は特に何もしていませんが、後始末などが必要であればここで行います。

ちなみに、スローされた例外を握りつぶしてしまう(再スローしない)と、SWFから見た場合そのアクティビティの実行がうまく行ったと判断されてしまいます。(タイムアウトなどを除いて)

例えば、アップロードに失敗したのに、ダウンロードがうまく行くはずがありませんが、前段のアクティビティがエラーになってしまった、という事実をSWFが把握出来れば、次のアクティビティの実行をきちんとキャンセルしてくれます。ですので、我々は例外に対して何も心配する必要はありません。

起きてしまったエラーはそれはそれとして心の中で事実として受け止め、大いに反省し、次のステップへの大いなる啓示として前向きにとらえた上で、えいやっ!とその例外をもう一度クラウドの中に放り投げましょう。

心広きSWFは、その邪悪なワークフローをしっかりと止める事が出来ます。



失敗したって、もう一度やってみればイイじゃないか。
さて、例外処理が出来て一安心ですが、実際に問題が起きた時に、そのリカバリーを誰がするのか?という事になります。SWFにはRe-Run(ワークフローの再実行)という機能があるので、それを手動(やそれに近い方法)で行う事も可能ですけど、今イチあか抜けないですよね。そういう貴方にFlow Frameworkが提供するのは、Exponential Retryです。つまり、自動リトライ機能です。早速これを実装してみましょう。

Exponential Retryでは、「何秒後にリトライを開始して、それを何回やるか」を設定します。例えば以下のような事が簡単に実現出来ます。
  1. アクティビティが失敗したら、5秒後にリトライ
  2. 1回目のリトライに失敗したら、10秒後にリトライ
  3. 2回目のリトライも失敗したら、今度は20秒後にリトライ
  4. 3回リトライしてもダメだったら、そのワークフローは終了
リトライの間隔はExponential(指数的)に倍増します。 実装は非常に簡単。@ExponentialRetryアノテーションを自動リトライさせたいメソッドに加えるだけです。ここでは例として、S3Activitiesのdownload()メソッドに自動リトライをかけてみましょう。


簡単すぎて、このスゴさが伝わらないんじゃないか?と若干心配ではありますが(笑)、ここで一旦立ち止まって、深呼吸をして、胸に手を当てて、本当にコレで良いのかよ〜く考えてみてください。


・・・
・・・
・・・



オレはこんなにもSWFに頼っていいのか・・・いくらクラウドが無限にスケールする、って言っても、何でもかんでもリトライさせるのは賢くないよね・・・


賢くリトライするべし
download()の実装で考えられる例外は、大きく分けて二つあります。
  1. S3のAPIエラー
  2. ローカルファイルシステムのI/Oエラー
2番目の原因がディスク障害だったりすると、これはどう考えてもリトライさせない方が良いですよね。その場合は、S3のAPI例外がスローされた時だけリトライする、という設定をしましょう。exceptionsToRetryという属性を追加します。


S3の例外は、先ほど作ったMyS3Exceptionです。オレオレExceptionをあえて作った理由はここにあります。「リトライするかしないか」と言う事を切り分けたかったからなんです。「あとで効いてきますよ!」というのは、ここの事です。

ちなみに、@ExponentialRetryアノテーションでは粒度が大きすぎる!なんて言う場合は、RetryDecoratorなんてのもあります。これはワークフローの実装の中で、Activityクライアントのリトライポリシーを動的制御したい、なんて時に有用そうです。 さらには、AsyncRetryingExecutorなんていうExecutorもあるようです。

え〜、両方とも使った事無いので、「ある」という事実だけお伝えし、コメントは控えておきますwwww

と言う訳で、複雑になりがちで、かつ信頼性の高いリトライ機能を組み込むのは非常に大変ですが、Flow Frameworkはこのように非常に簡単に組み込む事が可能です。


まとめ
以上、簡単にまとめてみましたが、自前でコレと同じ事を実装するとえらい大変な事になる事は皆さんお分かりでしょう。Flow Frameworkはこのように非常に実践的で、しかも簡単に作れるようになっています。

でも、一点、言っておきたいのが、設計をきちんとしておかなければ、このような有用な機能が全然活かせない、という点です。ここはある意味非常に難しい(笑)インターフェースをきちんと定義しておかないと、あとで「なまらわやくちゃ」になるので頑張りどころです。

これに関しては、中の人の名言がありますので、最後に引用させていただいて、JAWS-UG仙台の小泉さんにバトンを渡したいと思います!