2012年4月24日火曜日
2012年4月20日金曜日
2012年4月13日金曜日
[#Cloud #クラウド ] 1社のクラウドサービスで閉じたクラウド戦略であってはいけない理由
1社のクラウドサービスで閉じたクラウド戦略であってはいけない
昔からの言い伝えで、「全てを卵を一つのバスケットに入れてはいけない」という諺があります。イースターの祝日に良く行われる、イースタエッグの祝い事が毎年4月上旬に北米ではよく行われるが、きれいに色付けした卵を広場の所々に隠して、子供達が競ってそれをバスケットに入れて集める遊びである。この諺は、一つのバスケットに卵を全部入れてしまうと、万が一転んだ時に全部がいっぺんに割れてしまうので気をつけなさい、という意味である。
企業に於けるクラウド戦略を策定する際にも同じ様な論理が働く。
一社のクラウドサービス事業社に企業のIT資産を全て移行してしまうと、大きな失敗に繋がる可能性が高くなる、という事である。
ここで重要な事は、クラウドサービス事業社の立場としては、上記と全く異なる立場でお客さんに自社のサービスをプロモートする、という事を理解する必要がある。
実際、Joyent, Amazon, Rackspace, VMWare, HP, CloudSigma, 等のクラウドサービス事業社は、自社のSLAの強み、DRソリューション、セキュリティ対策、等自社のサービスが如何に堅強で安心してIT資産を預けられるかを具体的ににプロモートしている。企業間の競争というのはすばらしいもので、業界全体の質的な向上には非常に良い方向である、と言える。
問題は、リスク回避、という観点においては、どのクラウドサービス事業社も所詮、自社のデータセンタ内で閉じたソリューションしか提供していない、という事である。複数データセンタ間での多重化、バックアップ、プライベートクラウド連携によるハイブリッド化、等テーマは色々とあるが、クラウド事業社自体が重要障害を起こしたら全てが壊れてしまう、というリスクは依然残る。
最終的には、ユーザ自身が、クラウドサービス事業社に依存しないリスク回避の為の施策を考えて、実行に移す必要がある、という事を改めて認識する必要がある、というのが今後の最重要課題である、という事を主張したい、
実は、「一つのバスケットに全ての卵を入れる」、という行為自体は、えも言われぬ安心感を産む、という事も事実である。
何せ、問い合わせ窓口は一つだけだし、ベストプラクティス、当面に於いても専門家から統合的なコンサルを受ける事が出来るわけである。
このブログの筆者である、Mark Thiele氏は、Switchと呼ばれる、ラスベガスに拠点を置くjoyent
というデータセンターの運用を経営している会社のEVPである。
同氏は、FluidITというIT運用コンセプトを提唱しており、よりAgileで、より効率の良いITエコシステムを作る必要性を主張している。この中で、マルチクラウドを統合的に運用管理することによるリスク回避、地理的なカバレッジの拡大、アプリケーションの多様性、新規技術の早期導入、等の価値の大きさを特に重要している。
この記事でも同様のアプローチをしている。
幾つか、非常に興味深いポイントを述べる。
1）クラウド、特に複数のクラウドの運用はリスク回避を企業の責任として持つ際には不可避の選択になる。
2）マルチクラウドを効果的に運用、管理するコンポーネントの導入はその為に非常に重要な要件となる。
3）企業に於けるIT運用のガバナンスは、マルチクラウド管理のコンポーネントが持つべきである。各々のクラウドサービス事業社に企業のガバナンスするモデルは今後もどんなにクラウド事業社が成長してもあまり期待してはいけない。
もちろん、マルチクラウドを管理するインフラを導入せず、全て企業が各クラウドの運用管理を直接行う、という選択もある。マルチクラウド管理のコンセプトはまだ新しく、本当に信頼出来る技術ベンダーは誰なのか、選択するのもそう簡単ではない、という考え方もある。全て独自管理する手法を採用すると、それに伴う管理コスト、工数はそれ相当に大きくなる、という事は容易に想像出来る。場合によっては、クラウドを最初から採用しない方が安く済むのではないか、という考え方も出てくる。クラウドに投資出来ないで躊躇している企業や、SIはこの辺で大きく悩んでいるケースは良く聞く。
Thiele氏の例えを借りると、交通渋滞の中でフェラーリを運転している様なものである、と述べている。企業内のIT管理者は能力は高いが、その能力をマニュアルでマルチクラウドを取りまとめる事に注力してしまったら、実にもったいない、と言う事である。
まず、ユーザとして理解しなければいけないのは、マルチクラウド環境を構築する事によるメリットである。一般的には次の様な点が上げられる。
A) 負荷分散
B) IaaSコストの最適化
C) レイテンシー（Latency)の最適化
D) クラウド業界での障害に対するDR
E) クラウド間の資産の移動をビジネスプラクティスとして汎用化する
マルチクラウド運用は、さらにクラウド採用の最大の懸念要因である、セキュリティとプライバシーを解決する為のソリューションとして考慮する価値がある。各々のクラウドの運用状況を細かくモニターし、障害やそれ以外の要因でデータの保全性に影響する様な問題は早い段階で検知し、しかるべきデータの移動、複製、ロールバック、等の処置を自動化することが出来る機能は既に存在する。
これに限らず、クラウド上のアプリケーション業務の性能の確保、ロードバランス、自動プロビジョニング、等も同様の運用管理機能である。これらをIT管理者が常に複数のクラウド上を監視し、マニュアルの操作をするのではなく、マルチクラウド管理レイヤーがルールベースの自動化作業に置き換える事によって、IT管理業務をクラウドに移行しても、SLAを十分に確保することが出来る、という事が見える様になってくる、と期待する。またそうなると、クラウド、それもマルチクラウド運用も出るの採用に踏み切る為の判断材料を定量的に見積もることが出来る様になる、という事が期待される。
2012年4月11日水曜日
[#Cloud #クラウド ]GartnerのMagic Quadrantの分析によるクラウド業界の動向
この図は、Gartner Groupが昨年11月に発表した、同社としては初めてのクラウド市場に関するMagic QuadrantとHype Cycleのレポートから、Hype Cycleの表を抜粋し、その分析を行ったもの。
クラウドは、そのキーワードが登場してからかなりいろんな新しいキーワードが派生して登場しており、いくつかのグループ分け、分類なくしては非常に混乱の要因になる市場になって来ている事がこの表だけでもわかる。
次の様な4つの傾向と分類が考えられる。
1）IaaS、PaaS、SaaSといった、クラウドコンピューティングが登場した当時から存在していたキーワードは既にピークを越え、"Trough of Disillusionment"（幻滅、失意）の領域に入りそうである。これは、当初の大きな期待が持たれていたこれらXaaSといったキーワードは話題程の価値を業界全体に提供していない、という状況を反映している、と言える。当然SalesForce.comやAmazon Web Servicesの様に一定の成功を収めている企業も登場しているが、IT市場全体の規模と比較すると、まだごく一部のシェアを獲得している、と言う方が正しく、当初市場を席巻するのでは、と想像されていたクラウドは実はある特定の市場領域での成長に限定されている、という意識が特にエンタプライズ市場において持たれている、というのがGartner Groupの見解の様である。
2）Big Dataに関連した新技術に大きな注目が置かれ始めている。企業内のデータを如何に有効活用するか、特に大量の情報を整理し、必要な時に必要な情報を引き出せる能力、重複している情報を統合し、一元化する能力が基幹システムに要求されており、クラウドインフラを利用してそのデータを比較的安く一括管理出来るソリューションが期待されている。その技術としてHadoopやCassandra等のBig Dataが注目されており、それを利用するアプリケーションとして、クラウド上のBPM等が今後成長していく、と予測されている。クラウド利用事例の有効なモデルとして評価されていく事が想定される。
3）クラウド間コラボレーションは、クラウド利用が段々と定着し、企業内で複数のクラウドを利用する環境が出来た時に必要となってくる管理面での課題に対するソリューションの総称である。Cloud Collaboration、Hybrid Cloud Computing、Cloud Services Brokerage、CloudBursting等のキーワードは全て複数のクラウドを組み合わせてより高度なクラウドの利用方法を実現しようとする方式である。
4）クラウドセキュリティに関しては今後は強化されていく方向は業界全体が求めている事であり、具体的なソリューションが今後登場していくと期待されている。従来のOn PremiseやWebアプリケーションの導入/運用で要求されて来たセキュリティの提供をクラウド環境にも適用していく動きはある上、一部その業界標準化、もしくは業界をして受け入れることが出来るセキュリティ基準の様なものが作られていく事が想定される。
こうやってみていくと、クラウドビジネスは段々と実際に採用、導入、運用し始める事を通して生じてくる、より具体的な課題に話題が移行しつつある事がわかる。当然と言えば当然であるが、この中で一番押さえどころは、やはりセキュリティを明確に打出すクラウドソリューション、と言うところではないかと思う。定量的な評価がしにくいファクターである上、クラウド上のセキュリティの基準、と言う者が存在しないため、何を持ってセキュアなクラウドなのか、という共通の理解を得るのが難しいからである。
2012年4月10日火曜日
2012年4月6日金曜日
[#Cloud #クラウド ] RightScaleの観点から見たサーバオーケストレーションとAWS SWFの発表との関係
RightScaleの観点から見たサーバオーケストレーションとAWS SWFの発表との関係
Thorsten von Eicken, CTO 
SWFはRightScale内部でも数ヶ月の間既にバックエンドシステムのサービスの一つして利用しており、RightScaleの提供するマルチクラウド管理機能の開発の効率化に大きく寄与しています。
僕の観点では、自動化はクラウドコンピューティングの最も重要な機能コンポーネントだと考えてます。自動化は、企業に取ってビジネス面で重要な機能（Pay as you go（従量課金）、Scale On Demand（ダイナミックなスケーリング）、Resilency（問題に対する対応能力）、Predictability（障害検知、トラフィック検知）、等）を可能にするし、何よりもシステム全体の信頼性を上げる事に寄与します。クラウドコンピューティングの価値は、これらの自動化によるメリットをシステム全体に適用出来るインフラとして最適なのです。
RightScale社は、この自動化に関する開発投資に創業当初から力を入れてます。RightScaleの初期バージョンから自動スケーリング(Auto Scaling)の機能を通して、サーバの自動的なスタート/停止と共にCPU負荷等の監視機能を充実させていました。この自動化機能を経験すると直ぐにわかる事ですが、新しいサーバインスタンスをCPU負荷の増加に連携してスタートさせる事自体は至極簡単な事で、誰でも出来る事なのです。難しいのは、そのスタートさせたサーバインスタンスを既に動いているシステムにスムーズに統合する所です、仮想マシンの立ち上げに加えて、必要となるソフトウェアスタックをバージョン、設定情報を全て寸分違わず揃え、サーバプールへの追加のみならず、併設されているロードバランサやデータベースシステムとの接続もシステムを停止する事無く行う必要があります。RightScaleの機能の大部分は、これらの設定を速やかにプロダクションシステムに追加して安定稼働を保証する為の諸手続きを全て自動化する機能です。
RightScaleの将来バージョンは、このプラットホームの上に、Server Orchestrationの機能を追加開発し、提供します。Server Orchestrationは、RightScaleが管理する、サーバやデプロイメント等のリソースを自動的に管理出来るワークフロー言語を利用します。最初の機能セットは、次の3つのオートスケーリング機能をカスタマイズすることが出来る機能です。
1）自動的にスケールアップ／ダウンする台数と時間を指定する
2）新規のサーバを自動的に起動する
3）動いているサーバを停止する
RightScaleは、毎分ユーザが規定した判断ロジック(Unser-defined Decision Function)を確認し、サーバアレーをスケールアップ／ダウンすべきかを判断します。Decision Function機能は、単純に立ち上げ/停止すべきサーバの数を返し、RightScaleはそれに従ってサーバ管理を実行します。
さらに、Decision FunctionはAPIを通して監視データを収集し、他の機能も提供することが出来ます。例えば、アプリケーションの特定の状態を把握し、条件によってはサーバの立ち上げの予測も行う様なロジックを作る事も可能になります。
Decision Functionがサーバの増加を必要としたとき、RightScaleはスケールアップの為のワークフローを起動してサーバの立ち上げを条件に従って行います。サーバの数に加え、サーバを立ち上げる場所や条件を詳細に規定することが出来ます。スケールダウンも同様に詳細の設定に基づいて行う事が可能で、ログの取得、バックアップの確保、等を行ってからサーバを停止する様な処理も可能になります。
RightScaleのオーケストレーションの機能を開発するにあたり、2つの重要な要件についてよく議論しました。
1）Concurrency（並列処理）
複数のサーバに対して同時に処理を行える設計にしないと規定時間内に処理を完了する事が難しくなってきます。例えば複数のサーバを同時に平行処理で立ち上げる構造にしないと台数が多くなると時間がやたらとかかる処理になってしまいます。
2) Fault Tolerance（障害対策）
障害が発生した時に、システムの回復をする時にこそ、Orchestrationの機能が大きな効果を発揮します。障害発生時には、他のプラットホーム、若しくはクラウド上でで再起動を自動的に行うことが出来ます。障害回復先が同じ障害の影響を受けている場合、オーケストレーションの機能自体が障害の影響を受けていた場合は？上記のスケールアップ／ダウン機能の多重化も考慮する必要性が出てくる訳で、ワークフローの階層的な構築を行い、サブワークフローの障害を親のワークフローが引き継げる様な構造が必要になってきます。
この辺の並列処理と障害対策の機能をしっかりしたものにする為に、RightScaleのオーケストレーションシステムはオープンソースである、Routeと呼ばれるワークフロー管理言語を採用し、これをベースに開発する事にしました。Route言語は、タスクを並列的に動かす時に構造的な方法でその処理の運用を設定する事が可能になります。例えば、複数のワークフローを「並行に行い、全部が成功するまで待つ」構造にしたり、または「並行に行い、一つ成功したら他を全てキャンセルする」、等といった設定が出来ます。
Amazon Web ServicesのSWFはこのRouteワークフローを通して障害対策機能を強化した運用を実現することが出来ました。SWFをワークフロー処理を行うエンジンとして位置づけ、Routeを通して、AWSの提供する複数のAvailability Zone上のサーバに対するワークフローを並列に動かす事が出来る様にしました。SWFはスケジュールに則ったワークフローの実行を行い、結果を収集し、Routeに報告する事により、Routeが次のステップに移行し異なるワークフローの指示を出せる様な構造です。結果として、AWS環境上で起きうる様々な障害に対して、非常に可用性の強いオーケストレーションシステムが誕生する結果になりました。
SWFがオープンになった現在、順次このオーケストレーション機能をRightScaleを通して提供出来る様にする事を期待しています。早々にプライベートベータ版を提供すべく準備を進めている状況です。
2012年4月5日木曜日
クラウドAPI: APIの乗るアーキテクチャにむしろ着目せよ
Cloud APIs: It's the Architecture that Matters
Thorsten von Eicken, CTO
クラウドAPI: APIの乗るアーキテクチャにむしろ着目せよ
Thorsten von Eicken, CTO クラウド業界は相変わらず、活気にあふれている状況である。先日のAmazon Web Services社とEucalyptus社との間のクラウドAPI協業の発表に引き続き、OpenStack Summit開催の直前を狙って、Citrix社が自社のクラウドAPIの拡張に関する発表を行っている。この一連の活動を通して、いかにクラウドAPIが重要な要素になっているか、という事がよくわかる。特に今年は、クラウドAPIの市場はますます活発化するが、標準化どころか、複数のAPIがますますしのぎを削る市場が展開される、という事が予測される。
Citrix社の発表は、Cloud.com社がCitrix社に買収されてから初めての大きな発表になる、という点が特徴的である。買収後、Citrixチームと元Cloud.com両社共にOpenStackプロジェクトにかなりのリソースを提供し、具体的には、Swiftと呼ばれるOpenStackのストレージシステムの採用を行って来た。
興味深いのは、CloudStackのチームはOpenStackの技術を自社クラウド基盤に採用する事に関して非常にオープンではあった一方、特にOpenStack Compute部分を採用する事に関しては、少なからずとも抵抗が出て来ていたのも事実である。既にグローバルに数々の大規模パブリッククラウド事業社への導入実績を持っているCloudStackのチームにとって、OpenStack Compute部分は、技術的な面において遅れている、という認識が強くなって来た、というのが要因である。
結果的に、CloudStackの部隊としては既存のCloudStackの継続的な開発を続ける方針を維持し、OpenStackからは必要な部分のみを積極的に採用する、というスタンスをとる結果になっている。OpenStack Object Storageの採用はその一例である。
また、昨今発表したCloudStackをApache Foundation Projectに寄贈する件についても、CloudStackを独立したクラウドAPIとして競合力のある技術として位置づける方針が明確になった裏付けである。
さて、一方では、Amazon Web ServicesとEucalyptusは共同でAPIの互換性を保証する発表を行っている。従来から、Eucalyptusの主張していた、AWSとのAPI互換戦略をAWSと共に改めて市場にアピールするよい機会であったと言える。
AWSのクラウドAPIにかかわる戦略がクラウド全体の市場に与えている影響を考察すると非常に興味深いものである。Eucalyptusが登場し、RackSpaceがクラウド事業を展開し始めた当初、両社のAWS API互換戦略に対して、AWSがそれを防止するための動き、特に法的な処置に出ないかどうか、実は市場が興味深く動向を観察をしていた時期でもある。AWS内部でも、どの様な対応を取るべきか、かなりの議論がされていた筈である。結果的にAWSが取った戦略は、"Wait And See"（様子見）戦略で、市場の形成がもう少し進んだ時点で行動を起こす、というものであった。その行動の一つがEucalyptusとの発表である、という事が言える。
かなり早い段階でもう少し具体的な動きを取るべきだったのでは、という議論もある。例えば、Ubuntuの開発者である、Mark Shuttleworth氏が2011年の9月時点で、OpenStackはAWS EC2互換であるべき、と主張している。また、CitrixのCloudStackも以前よりAWS API互換をサポートしている、という実績があり、AWS APIに関する各社、団体の動きというのは市場全体に共通するクラウド事業社にとってのベンチマークAPIである、と言える。
さて、本題は、このクラウドAPIというもの、本当にそんなに大事なものなのか？ という疑問であり、クラウドAPIの互換性というものの本当の意味について分析をしてみたい。
クラウドAPI互換の問題点
以前から主張しているが、改めて述べたい。重要なのはクラウドの中のリソースのセマンティック（意味的な構造）であり、その表面上のAPIではない、という事である。
API互換は、かなり深いレベルまで互換性を確保しないと全く意味をなさない、と言う事である。
幾つか事例を通して解説をしてみたい。
＃1：
EC2は幾つかのインスタンスタイプを提供している事は有名である。1~8個のコアCPU、512MB~8GBのメモリ、ディスク0〜4スピンドル、共有ネットワークと専有10Gbpsポート、等々。これらの多種のインスタンスをプライベートクラウドに構築するのは可能ではあるが、実際問題そんな簡単な話ではない。結果的にAWSと異なるインスタンスタイプのあるプライベートクラウドにAWS上の資産を動かそうとしても結構難しい問題が発生する。また、AWSのインスタンスタイプが必ずしもユーザのアプリケーションに最適なデザインであるとは限らず、事例としてカスタマイズしたインスタンス構成を自分で作るエンドユーザも非常に多いのが実情である。この辺はクラウドAPIとは全然次元の違う課題の代表として上げられる。
＃2：
EC2 EBS Block Storageは非常にユニークが構造を持っているストレージクラウドである。それ故、好き嫌いも多いが、スナップショットや特定のI/O向けに多用されいているのが現状である。ただ、それは事実上無尽蔵にストレージを提供出来るAWS上でこそ効果を発揮する性格の技術で、小規模なプライベートクラウド上では、EBSと完全互換のストレージを提供する事はあまり意味が無い、と言える。API互換を追求するあまり、あまりシステムとしては効果の無い環境を提供する結果になってしまっては、あまり意味が無いのでは、と感じる。
＃3：
AWSクラウドは、それぞれのリージョン毎に分離され、それぞれが独立してリソースを管理/運用している。障害管理(Disaster Recoery: DR)の目的で、東海岸に一イメージ、さらに西海岸にそのイメージのコピーを作りたい場合、ある特定の頻度でイメージをコピーして同期させる必要がある。多くのクラウド事業社は、こういった複数のリージョン間のイメージ管理を自動化、若しくは簡易化したサービスをAPIとして提供している。当然、各社とも、そのアプローチ、ましてやAPIはバラバラである。AWS互換のレベルとは全く次元の異なる世界である。
＃4：
SoftLayer社は、世界各所で運用しているデータセンタとそれを繋ぐネットワークインフラを利用し、顧客に対して、グローバルなプライベートネットワークを提供するサービスを行っている。AWSのリージョン別戦略と異なり、拠点間のアドレスを統括し、一つのサーバシステムの様に見せることが出来る、というのが特長である。拠点間のサーバ管理、上位の業務運用がEC2と比較して非常に簡易になる、と言う事である。SoftLayerはその気になれば、AWS EC2互換をグローバルに提供する事も可能であるが、そうしたとしても、拠点間で運用管理をする為のツール、インスタンスの提供/管理を支えるアーキテクチャがAWSと大きく異なる為、クラウドAPIを共通化した所であまりユーザにとってメリットの無い話になってしまう。
要は、クラウドAPIはクラウド間の互換性やポータビリティを保証する要件にはなり得ない、と言う事である。単一のインスタンス上でサーバを数台起こす程度であれば、API互換は何かと重宝するが、一旦要件が、異なるクラウドへの拡張性、性能の最適化、コスト最適化、ガバナンス/コンプライアンス、障害検知/対策、等の対応を必要とする状況になった時点で、クラウドAPIだけでは到底カバー出来ない課題がうまれてくる。
互換性に対するより大きなアプローチ
上記の状況に対して、より大きなアプローチが必要になってくる、という事は自明である。
まず、現実問題としてAWS APIに加え、他にも複数のクラウドAPIが存在する、という事実を認識する必要がある（特に日本では顕著）。また、EC2には、2種類のAPIが存在する、と述べたい。"EC2 Classic"と"EC2 VPC"の2つである。後者は、AWSのVirtual Private CloudをサポートするAPIであり、Classicとはかなり異なるAPIを提供している。例えば、VPCは、i) Classicがサポートしない、egress ruleがあったり、ii) Classicが1コマンドで出来るしないインスタンス間のIPアドレスの移行に2コマンド必要である、等。
細かい事はさておいて、本質的な課題を述べると、"Amazon準拠"の真の意味は、AWSが提供している、20にも及ぶサービス全てに対して互換性を提供する事、と定義する必要がある。ただ、これ自体は大変な事であり、口でいう程簡単ではないのは明らかである。
多くのAWS互換クラウドは、EC2に加え、それに準ずるサービス、例えばElastic Load Balancing(ELB)、Relational Database Service(RDS)、Simple Queue Service (SQS)、場合によってはCloudFrontのコンテンツ配信サービス等が上げられる。その程度の互換性で上手くAWSからの移行が成立すればOKだが、問題は、自分の利用するAWSサービスが一つでも欠けていたら、AWS互換の価値が全く無くなってしまう、と言う事である。
今後の傾向としてよく理解しないといけないのは、クラウドユーザは、EC2レベルのAPI互換性ではなく、その周辺のサービスに対する互換性がより重要な課題になる、という点である。
例えば、RackSpace Hosting社は、Load Balancingをサービスとして提供を開始しており、一方では、SoftLayerはCDNサービスを提供している。Google AppEngineを見ると、Task Queues、Emailサービス、各種SQL/NoSQLのストレージサービス、等、各社サービスメニューを拡充している。また、まだ付加価値サービスを提供していないクラウドベンダーはこのサービスメニューの品揃えの重要性に早くも気づき始めている。
今時点に於いては、AWSが提供しているサービスメニューに非常に近いものが多く登場しているのが現状であるが、今後どのような新しいサービスが登場するのか、またサービス群全体としてのクラウド間互換性の動向がどの様に進むのか、が非常に興味深い所である。
まとめ
Citrixの発表した、i) 自社技術の優位性、ii) Apacheへのソース公開、iii) AWS互換性、の3点発表は興味深い戦略である。今後起きうるトレンドとして、オープンソースになったCloudStack上に、AWSの各種サービスと互換性を持つコンポーネントを開発するベンダーが登場してくるだろう、という点である。そういう意味では、Citrixは市場動向をよく分析した、非常に戦略的な動きを取っている、と評価することが出来よう。
今後の提案として2つあげたい。
1）AWSにとらわれる事なく、今後登場する他のクラウドも積極的に利用し、新たなユースケースを発見して欲しい、という事。
2）その際には、クラウド間の互換性について悩むがためにより大きな動向を見失っては行けない。
各種サービスも含めた、クラウド間の互換性、ポータビリティ、についてはより上位のレイヤーにおいて既に取組んでおり、ソリューションとして成立している、という事を是非認識して欲しい。
RightScaleの元来狙っている答えは正にそこにある訳です。
登録:
投稿 (Atom)