はじめに
3月11日(土)にTOC五反田メッセで開催されたJAWS DAYS 2017に参加してきました。私は仕事でAWS
を触ったことはありませんが以前から興味があったため参加しました。各セッションとも非常に面白く、会場も活気があって良い刺激になりました。
忘れないよう聴講したセッションのうち以下4つのメモを書きます。なお、スライドの内容以外でスピーカーの方が話した補足事項を書いていますので、スライドと併せて読んでいただければと思います。
- 赤ドクロ Presents 『AWSで開発するならこれやっときゃいいよ的な話』(仮)
- サーバーレスでシステムを開発する時に大切な事
- コミュニティで拓く、パラレルキャリアへの道
- サーバレスの今と未来
赤ドクロ Presents 『AWSで開発するならこれやっときゃいいよ的な話』(仮)
スライドのリンク: https://www.slideshare.net/keisuke69/aws-73040279
アーキテクチャのベストプラクティス
スライド8枚目~
本セッションはWebアプリケーション主体の話でしたが、それに限らず全般的に適用できる話とのことです。
まず、アーキテクチャのベストプラクティスとして7つの原則を紹介されていました。
PDFですが元ネタはこのあたりでしょうか。
https://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
Twelve-Factor Appについて
スライド49枚目~
Heroku
エンジニアが公開したWebアプリ開発のための方法論で Webエンジニアなら一度は読むべき とのことでしたので後で読もうと思います。日本語訳はたぶんこれです。
DevOpsについて
スライド59枚目~
本セッションではDevOps
を「文化+実践+ツール」と定義しており、このうち最も重要なのは 文化 であると言っていました。 文化 が根底にあって、それを考慮した 実践 を ツール を用いて実現するということでしょうか。また、スライドにもある通り実現した結果「開発者から顧客へのサービス提供と顧客からのフィードバック、つまりライフサイクルを高速化すること」がDevOps
であるとしています。
サーバーレスでシステムを開発する時に大切な事
スライドのリンク: https://www.slideshare.net/hiroyukihiki/ss-73049142
EC2のとなりのサーバーレスである意味?
スライド10枚目
ここまでの話はlambda
は使いどころが難しく、実行回数制限や処理の正確な実行が保証されない(何回も実行される可能性があり冪等性が保証されないという意味であることを後でTwitter
にてフォローされていました)点を完全に考慮し、非同期処理前提の分散アーキテクチャで設計をする必要があるというものでした。
サーバーレスは設計が非常に難しく、もしEC2
で代替できる(lambda
を使う明確な理由がない)場合はなるべくEC2
に寄せた方が良いとのこと。特にEC2
とlabmda
を中途半場に混在させると悲惨なことになる、という話があったと記憶しています。
MBS動画イズム444について
スライド12枚目~
月々のインフラ運用コスト削減のためlabmda
を使用し、3ヶ月程度で構築したというシステム開発事例の話でした。(詳細な資料はここを参照)
およそ3ヶ月という短い期間であるにもかかわらず、大量アクセスに対する仕組みや長時間処理の対応、障害対応やセキュリティ面を考慮した設計をされており、本当に凄いと思いました。また、成功要因の大きな理由にkintone
を使用したことを挙げていました。kintone
を使用して画面など作成したことで開発効率をかなり向上することができたそうです。
まとめ
スライド22枚目
サーバーレスは運用コストをかなり抑えられる反面、開発時のコストがかなり高くなってしまう問題があるようです。これは高いスキルを持った人が設計しないと死ねるという理由もあるかと思います。そのため、コンペでSIerと競り合うとほぼ負けてしまうというのが現状であり、もしサーバーレスでやるならコンペ参加者全員がサーバーレス開発を条件にしてもらわないと勝つのは非常に難しいとスピーカーの方が嘆いていました。
私見メモ: コンペというのはおそらく一般競争入札またはそれに準ずるものだと思います。入札の種類は大きく分けて総合評価方式と最低価格落札方式があり、総合評価は時間もかかるし発注側にも評価できるスキルが必要になるため、条件にもよりますが最低落札価格方式が採用されることが多いと感じます。
最低落札価格方式では、システムをどう実現するかは考慮されず価格のみの勝負となるため、適当な見積もりをした会社や何でもいいから仕事が欲しいと異常な低価格を提示する会社が来る可能性があり、それをやられたらほぼ勝ち目はありません。
また、開発と運用は別の入札案件になることが多く、こういった理由がスピーカーの方の嘆きに繋がっているのだと思います。
MBS動画イズムの受注はここにもある通り、期間やモダンなシステムの提案、レスポンスの速さなど金額以外の部分が結構な割合を占めているのかなと思われます。
コミュニティで拓く、パラレルキャリアへの道
スライドのリンク: https://www.slideshare.net/hide69oz/20170311-jawsdays
ボーリングピン戦略とは?
スライド20枚目
ボーリングでストライクを狙う場合、球をいい感じの軌道とスピードで数本のピンに当て、そのピンが連鎖的に他のピンを倒してくれるよう狙うと思います。この例えをマーケティングの世界に適用したものがボーリングピン戦略です。スライドではピンを コミュニティ・パートナーエコシステム と表現しています。このセッション通して、全てこの戦略に通じていると感じました。
なぜパラレルキャリアになろうと思ったのか?
スライド23枚目~
AWS
は巨大でパートナーや顧客も多く学ぶべきことはたくさんあったとのことですが、当然それらは全てAWS
に閉じているという問題がありました。時代が進んでいくに連れ、このままでいいのかという疑問が大きくなり、AWS
以外のモノサシに触れる機会を作りインプットを多くしようと考えたのがきっかけとのことです。
複業を決める際の要点は?
スライド29枚目~
時代の流れを要点としたようで、大きくは以下の2つです。
- クラウドエコシステムが作り出した一つの「不可避」な流れ クラウド自体は別に目新しいものではなく昔からそういった概念は存在していました。(DWHとかですかね)ビッグデータも呼称される以前から形は違えどデータそのものは存在してた。重要なことはこういったワードではなく、巨大なコンピューティングリソースや大量で不統一な形式のデータを扱えるエコシステムが時代の流れと共に整ってきたことにあること。
- 人口減少というもう一つの「不可避」な流れ もう一つは日本単体で見た場合の人口減、インバウンド、デジタル輸出など。
スライドではVR
やIoT
などもこの流れの中に含まれており、この時代の流れは購買・販売・決済行動に大きな変化をもたらします。この変化の中にいられるよう複業を決めたとのことで、これから大きく変わる可能性のある分野、変化のある世界を求めて複業を決めるのが良いとのことでした。
実際、複業は大変では?
スライド43枚目~
各会社側からは当たり前ですが他社で働いてる間の業務量は見えないため、他のフルタイム社員からは同列の社員として扱われます。すると他社で仕事をしている間は社員には見えないため「あの人、きてないけど」とか「あの人レスポンス遅いんだけど」等の問題が発生するようです。こういった問題を極力回避するためにも期待値コントロールが必須であることを言ってました。また、複業ではチャットの活用が必須に近く、チャットを禁止している会社だとかなり厳しいと思われると話されていました。
まとめ パラレルキャリアはオススメできるか?
スライド53枚目~
多くのインプットが欲しい人にはとても有効ですが、コミュニティに従事していないとまず今の日本では無理とのことでした。私も聞いてて無理だなこれはと思いましたが、それはそれとしてパラレルキャリア関係なく、コミュニティを活用することは非常に有益であり、必ず自分のキャリアの役に立つという話は同意でした。
サーバレスの今と未来
スライドのリンク: https://www.slideshare.net/YoshidaShingo/serverlessnowandthen
サーバーレスエコシステムについて
スライド15枚目
サーバーレスエコシステムとは「AWSやAzureなどのプラットフォーム」「開発・運用フレームワーク」および「実際のアプリケーション開発者」の3つで構成されており、互いの連携が大切とのことです。特に近年不足していると感じるのが開発者の部分で、情報発信が非常に少ないと話していました。そのため、午前中のセッションにあったCloudPackさんのlamdba
話や日経新聞社の紙面ビューワーでlambda
を使用した事例の話などは大変貴重とのことでした。
サーバーレスでやれることは?
スライド20枚目~
無理にサーバーレスにする必要はなく「サーバーレスだからこそできることをサーバーレスでやる」ことが望ましいとのことです。ここで、去年開催されたServerlessConf
のうち、2つのセッションが紹介されました。
1つ目はタイトルが10X Product Development
、つまり10倍の生産性開発という内容で、得意ではないところをサーバーレスに任せていく方針が良いという内容でした。それに対し、本当に任せきりでいいのかという問いと共に2つ目のセッション内容が紹介されました。結論として、任せきりでもそのサービスの技術情報や構成はちゃんと理解し、障害が発生した際どう回避すればいいのかを把握しておく必要があるとのことでした。また、技術的には明るいがお金が流入してなさそうなサービスに完全に乗っかるのは危険とも言っていました。
サーバーレスSPAの開発の流れ
スライド34枚目~
サーバーレス開発をする際はテストコードをこまめに書いたほうがよく、テストがないと後で悲惨なことになるとのことでした。これはサーバーレスで組んだシステムは複雑になりがちなのでエラー解析がかなりしんどいからと推察しました。